9

I am trying to understand permissions in detail. I was reading about setuid and it's uses. However, this particular case confuses me.

I have made a small script and now I have set the suid bit for the script as below. 

chmod u+s ramesh

I see the permissions set as below. 

-rwsrw-r--  1 ramesh ramesh   29 Sep 30 10:09 ramesh

Now, I believe with setuid any user could execute the script. Now, I did the command

chmod u-x ramesh

It gives me the permission as,

-rwSrw-r--  1 ramesh ramesh   29 Sep 30 10:09 ramesh

Now, I understand the S denotes setuid with no executable bit. That is, no one can execute this file.

So my question is, what practical purposes do the setting of S bit have? I am trying to understand from an example perspective for setting this bit.

Ramesh
  • 39,297

3 Answers3

8

Now, I believe with setuid any user could execute the script.

Not quite. To make the script executable by every user, you just need to set a+rx permissions:

chmod a+rx script

setuid means that the script is always executed with the owner's permissions, that is, if you have the following binary:

martin@dogmeat ~ % touch dangerous
martin@dogmeat ~ % sudo chown root:root dangerous 
martin@dogmeat ~ % sudo chmod a+rx,u+s dangerous 
martin@dogmeat ~ % ll dangerous 
-rwsrwxr-x 1 root root 0 Sep 30 17:23 dangerous*

This binary will always run as root, regardless of the user that is executing it. Obviously this is dangerous and you have to be extremely careful with setuid, especially when you are writing setuid applications. Also, you shouldn't be using setuid on scripts at all because it's inherently unsafe on Linux.

Now, I understand the S denotes setuid with no executable bit. That is, no one can execute this file.

So my question is, what practical purposes do the setting of S bit have? I am trying to understand from an example perspective for setting this bit.

I don't think that there is a practical purpose, IMO it's just a possible combination of the permission bits.

dr_
  • 29,602
Martin von Wittich
  • 14,187
4

One purpose of having a file non-executable but setuid and/or setgid is to then use an access control list (ACL) to allow only certain users to execute that file. If you want to run a command with setuid root, but, for example, you don't want everyone to be able to run that command. If you only want certain users or certain groups to be able to run it, you might forbid execution in general then allow limited execution with an ACL.

The following example takes a fictitious command and makes it generally non-executable but setuid, then uses an ACL to allow members of the adm group to run it:

$ 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

So, according to the file permissions, the file is setuid but not executable (or even readable). However, the access control list gives read and execute privileges to all members of the adm group.

If a member of the adm group executes the file, it will execute with the setuid privileges that the file has, under the executable privileges granted by the ACL. If anyone else tries to execute it, they will get a permission denied error.

Doing a directory listing of the file after the above setfacl command will show:

$ ls -l privileged_command
---Sr-x---+ 1 root     root     152104 Nov 17 21:15 privileged_command

This seems to show that the root group has read/execute privileges on the file, but really is just indicating there is an acl that gives read/execute privileges.

This is one example of where you might want to have a program as setuid but not (normally) executable.

Kurt Fitzner
  • 197
  • Interesting example, but it doesn't *entirely* make sense — especially in your example where the file is setuid to root (and hence owned by root) — turning off the 0100 bit means denying execute permission to root.  With the possible exception of SELinux and things like it, denying permission to root is generally a no-op.   And even if the file was owned by fred, why would you deny fred permission to execute a program that's setuid to fred?  Besides, if fred owns the file, he can always change the permissions. – Scott - Слава Україні Nov 18 '18 at 02:05
  • I guess I was more linking setuid/setgid together. For strictly setuid, you're right that it prolly doesn't make sense denying the owner execute. Or anything, for that matter. That'd be an interesting case. – Kurt Fitzner Nov 18 '18 at 06:41
  • Yeah; I meant to add that your answer works better for setgid than it does for setuid, but I forgot  /  ran out of characters. – Scott - Слава Україні Nov 18 '18 at 06:46
3

All permission bits can be set or cleared independently. Some combinations are very common, others serve no practical purpose. ls uses a capital letter S to mean “s without x” to highlight that this is an odd, possibly erroneous setting.

If a file is not executable by anyone, its setuid and setgid bits are not relevant. Keep in mind that even if the file's traditional unix permissions have no x bit set, there may be an ACL that allows some users or groups to execute the file.

On many Unix variants, including Linux and Solaris, the setgid bit on a directory controls whether files created in that directory inherit the directory's group ID (BSD semantics, used when the setgid bit is set) or the process's effective group ID (System V semantics, used when the setgid bit is clear).

On Solaris, the setgid bit on a regular file that is not executable activates mandatory locking. Mandatory locking allows locks set by the fcntl lock mechanism to be mandatory, i.e. if one process has the lock and another process doesn't use any lock, then the second process will not be able to access the file.

Gilles 'SO- stop being evil'
  • 829,060