2

As I understand, the setuid bit means that any user who can execute a file executes it as the file's owner. Is it possible, using ACLs or something, so that only a select list of users execute the file as the owner, and everyone else executes it as themselves?

I'm thinking of it as a lightweight alternative to sudo. Or do I have to use sudo (or su) for this?

  • 1
    If you are wanting suid-root, then the inherited bits of capabilities may be of use. – ctrl-alt-delor Nov 17 '18 at 11:43
  • Hmmm, something like set cap_sys_admin only for those users? I googled and got stackoverflow.com/a/17685265 ... but that looks waaay more complicated than I was hoping for. – user321445 Nov 17 '18 at 11:47
  • Seems like we need some sort of not so hard-link. On a cow file-system then you could just copy the file. I hope you get an answer, as I am interested. (Are you using suid to get root privileges, or to be some other user?) – ctrl-alt-delor Nov 17 '18 at 11:49
  • 1
    Can you add more about your use-case? I think that if we know what you are trying to do, then we can choose the best mechanism. – ctrl-alt-delor Nov 17 '18 at 11:51
  • Both, actually. There are commands which are set to be run only as some limited user, and I figured this could avoid the need for sudo (and all the complications - environment, etc.) that that brings - if all I wanted to do was run a command as another user. – user321445 Nov 17 '18 at 11:52
0

It is not possible the way you want it, where if one user executes the file then it is executed setuid, but if another user executes the file it is executed without setuid. The setuid bit is not included in access control lists. It is either on for a file or off.

You can get partially toward your goal. You can allow only certain users to execute a setuid file, but other users will be forbidden from executing it at all.

For example, consider the fictitious "privileged_command" program. If you want to make it setuid but only allow members of the adm group to run it through an acl, then you can do this by:

$ chown root.root privileged_command
$ chmod 4000 privileged_command
$ ls -l privileged_command
---S------ 1 root root 152104 Nov 17 21:15 privileged_command
$ setfacl -m g:adm:rx privileged_command

This is a very simple example, and very doable with just group permissions. But you can go on to use setfacl to make a complex set of users/groups who can and can't execute the program. The only issue is, everyone who is capable of running the command will run it setuid. Anyone else will just get permission denied and won't be able to execute it at all.

This is as close as I can think of get to what you are actually asking. That being said, what you are asking is probably a Bad Idea™. Best practices for extra privileges are for users who are authorized to exercise those privileges to be required to actively assume that authority when and only when they intend to act with that authority. This is the whole purpose behind sudo. Making certain commands automatically act with different privileges depending on who is executing them is a recipe for accidental misuse. That's the reason why you don't normally just log in as root all the time.

Also, the use of ACLs this way is a recipe for later security holes. ACLs are rarely used, and even more rarely needed. In this case, using them to control who can run a program setuid, it's not immediately obvious who has what privileges, there is no central file or repository showing who has what authority, or what ACL conditions are on which files. It can quickly become an administrative nightmare.

I won't say that there is never a place for using an ACL, but I can count on one hand with a lot of unused fingers the number of times I've seen a convincing case that it's a good idea.

  • Thanks. I'll stick to using sudo then. – user321445 Nov 19 '18 at 13:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy