I don't see any Unix daemons on my machine (running in single-user mode) that aren't running as root, including cron. All the Core Services run as heather, and the web server runs as www.
At 5:58 PM -0800 1/17/03, Rich Morin wrote: >At 8:23 PM -0500 1/17/03, William H. Magill wrote: >>Every process DOES start out running as root and the process itself >>must make the effort to change to another userid. > >I'm not at all sure that this is true. A process that is forked off >of init will start out as root. If init's code doesn't cause it to >change its UID, it will remain running as root, even after it execs >a different set of code. > >OTOH, if I run a C program from the command line, my shell process >will fork, yielding two copies of the shell process, both of which >are running as "rdm". One of these will then exec the C program, >again as "rdm". This is true. The man page for fork( ) implies this when it says that the child process is an exact copy of the parent and inherits its descriptors. UID is always inherited from the parent. Many a nasty security hole arose because of a program that does a SETUID to a more privileged UID and then allows shell escapes, which then run as the more privileged user. But I think that the first point is valid in context. System processes are almost always forked from root and so have to have their UIDs set to a less-privileged UID. And if you're going to play on Unix, it's always a good idea to be mindful of your program's UID. The default's often not what you want, one way or the other. >P.S. I ran into an amusing bug in SunOS a decade or so ago. You could > su on your local machine, then su to nobody, then rlogin to another > machine, ending up with a root session on the remote machine. The > code in rlogin did a setuid to "nobody", failed, ignored the error, > and gave you a root shell! There was a very similar bug in Ultrix. Of course, 10 years ago, there must have been 50 ways to get a root shell on any machine where you lacked the root password. Unix, in general, was about as secure as a sieve. -- Heather Madrone ([EMAIL PROTECTED]) http://www.madrone.com If we're not having fun, we're not doing it right.
