General Question on SUID

I'm a little confused about SUID, particularly running as root.

In the beginning, I would revert to 'Windows Mode' and compile apps to run as root, just so I could get them going and get my hands dirty. This is no longer good enough for me, so I'm reconfiguring things to run properly.

But I find myself wondering about things running as root. Basically, how is that they can do this? How is it that a normal user cannot just write an app that goes root and does what it wants?

Is it because the daemons are launched by Init, which is itself running as root, and it is allowed to 'bestow' this status on its children? Is that I need to be root when I manually start or stop a daemon? This is what it seems to be to me, how close am I?

Any illumination, clarification and correction always appreciated.

You can only set permissions on files that you own. Thus, only root can enable the suid bit on a root-owned file.

Note that suid does _not_ necessarily mean that the program will run as root. It will run as the owner of the executable, whoever that is. So regular users can set this bit on their programs to cause them to run as their UID if the program is run by another user. This is occasionally useful, as with CGI programs run by the web server.

Basically, yes. ID's are inherited over a fork() and generally speaking only root can change to another user ID except via the suid mechanism. All non-kernel processes running on the system were directly or indirectly forked from init, which is started with UID 0 (the only one that is special to the kernel).

In terms of interactive logins on the console, login or xdm is started by init, which is running as root. Login checks credentials and then changes to the selected UID before execing the user's shell. User can't change id again without going through a program like su, which is installed as root-owned with suid bit set.

Kernel's role is to check that requested operations are allowed for the UID that made the syscall (and changing UID requires a syscall). Note that the kernel does not enforce mechanisms for checking credentials at login, which is why admins can configure that in various ways (PAM, kerberos, /etc/passwd, LDAP, etc).

Things work similarly as far as group ID as well, except that a user can be in more than one group (see 'man 2 setgroups'.

In general daemons can be run by any user. In fact, most of the time you want to avoid running them as root unless it is necessary. Some need root priviledge to get access to a specific resource, such as a network socket below 1024. Many of these daemons (e.g. Apache, BIND) will then switch to another user after acquiring the resource.

Obviously, programs that need to be root to acquire a resource need to be started by root. Others are started as root because the boot scripts run as root, but then change to other UID's.

This is not accurate. An executible runs as the user that started the process.

Example: create long running perl script called test.pl. do a for loop with 1000000 iterations that prints out the value of your counter. then: # chown root:root test.pl # su nobody # ./test.pl

While it is running, open another shell and start top. Look for the perl script running in top. it will show nobody as the owner of the process. The person that owns the file has nothing to do with the user that the process executes as.

If you are setting your apache files to be owned by nobody:nobody, you should fix this as you are open to PUT, unless you have PUT disabled.

cheers, 2minute brother

I stand corrected. I should put down the cup.

cheers, -2minute brother

Unless the suid bit is set.

Actually you're not quite right either. The example, test.pl, is a PERL script and scripts do not run suid. In the case of PERL there is a programme cannel suidperl that will run scripts setuid. It is only binaries that will have the euid set to the file owner when the SUID bit is set.

Not so. A simple perl script:

cat /tmp/test.pl

#!/usr/bin/perl -w

while (1) { sleep 60; }

chown mysql /tmp/test.pl chmod 4755 /tmp/test.pl

id uid=500(rgc) gid=100(users)

/tmp/test.pl& [1] 27622

mysql 27622 0:00 /usr/bin/perl -w /dev/fd/3//tmp/test.pl

If you try and run perl interactively when it is suid then it will complain. I'm not advocating doing this. Just pointing out how it works. Now this is Linux. I think Solaris behaves differently but you can override it even there if my memory is correct.

[ This may seem complete mess, because I digged up even the most obscure behaviour of Linux with respect of process credintals I could understand, but don't panic, there are so obscure behaviour that even I don't understand it from the source code :-> -Ilari ]

Datagram from Mike. incoming on netlink socket

Not exactly. In normal cases (nons[gu]id executable executing another nons[gu]id exececutable with no weird priviledge settings), they do.

Here are exceptions I know:

1) All cases:

-Saved UID does not inherit. Instead it is set equal to EUID. -Filesystem UID does not inherit. Instead it is set equal to EUID. -Saved GID does not inherit. Instead it is set equal to EGID. -Filesystem GID does not inherit. Instead it is set equal to EGID.

2) Additional for Processes with effective or real UID