0

I implemented a pluggable authentication module (PAM) called checkConnections.

I initially put this executable in /usr/local/sbin/ because Filesystem Hierarchy Standard says locally installed system tools go to this place. Thus the executable is used like this

session required pam_exec.so stdout /usr/local/sbin/checkConnections 10

This works fine but regular users are able to see this executable through tab-completion because /etc/environment adds /usr/local/sbin to PATH.

My goal is that my system administration tools shall not pollute regular users' views. They by default shall not see my system administration tools.

I was thinking to remove sbin folders from /etc/environment, but https://askubuntu.com/a/866169/703866 recommends against that.

At least you should not remove any of the important paths like /bin, /sbin, /usr/bin and /usr/sbin from it.

If I put checkConnections to somewhere else, I don't know what's the best or standard place.

Please advise.

Gqqnbig
  • 689
  • 3
    I understand what you're trying to do, I just don't get why. Have your users actually complained about your sysadmin tools showing up in tab completion? If not, why are you solving a problem that doesn't exist? Or are you worried they'll actually run these programs? If so, why aren't the permissions fixed? (Generally tab completion doesn't show commands which the user can't execute anyway) – muru Aug 23 '21 at 05:39
  • @muru I want to learn and follow standards. If I hadn't been doing this, I would not have known Filesystem Hierarchy Standard. If I hadn't cared encapsulation, I would have marked all my classes public. – Gqqnbig Aug 23 '21 at 10:09
  • You have the standards. It's perfectly fine by FHS to keep these scripts in /usr/local/bin. And in some languages, everything is "public" anyway and encapsulation is a matter of conventions. You can't apply your public/private/whatever to those, now, can you? – muru Aug 23 '21 at 11:30
  • If you are determined to do this, then the closest candidate is probably a pam subdirectory under /usr(/local)/lib/ ("it may also include internal binaries that are not intended to be executed directly by users or shell scripts") – steeldriver Aug 23 '21 at 11:54
  • ... there's also /usr(/local)/libexec/ ("internal binaries that are not intended to be executed directly by users or shell scripts"). AFAIK that's is more of a RH thing though. See also What is the purpose of /usr/libexec?. – steeldriver Aug 23 '21 at 11:55

0 Answers0