Score:0

Best place for pam_exec.so executable?

cn flag

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.

muru avatar
us flag
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)
cn flag
@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`.
muru avatar
us flag
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?
hr flag
If you are determined to do this, then the closest candidate is probably a pam subdirectory under [/usr(/local)/lib/](https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s06.html) (*"it may also include internal binaries that are not intended to be executed directly by users or shell scripts"*)
hr flag
... there's also [/usr(/local)/libexec/](https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html) (*"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?](https://unix.stackexchange.com/questions/312146/what-is-the-purpose-of-usr-libexec).
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.