> The permissions of files in /proc/1 (usually belonging to init) are> kept as they are. The idea is to let system processes be freely> visible by anyone, just as before. Especially interesting in this> regard would be instances of login.

I think you mean login shells, the login process is just the thing askingfor the password agter the (m)ingetty got the username. These processesare usurally created with the '-' sign in argv[0][0], but the users mayreplace that string at will. I think it's still OK to depend on that ifyou want a semi-secure system.

> I don't know how to easily> discriminate between system processes and "normal" processes inside> the kernel (apart from pid

Do you mean ppid?

> == 1 and uid == 0 (which is too broad)).> Any ideas?

This feature seems to be frequently requested. I don't remember the outcome, though.

From a quick view, it seems the symlinks in /proc are empty for kernel threads and non-empty for user processes. Since you're messing with the proc entries, this could be a cheap way to find the kernel threads.Another possibility is by looking at the blocked signals, signal 9 may not be blocked by mortals.

For the system daemons, you could additionally check for the absence of a controlling tty, but that's still no safe distinction from a process run by nohup. Checking for sid=pid will filter additional processes, but it the shell in midnight commander and screen are still false positives.Checking for */sbin*/ in $PID/command will fail as soon as the daemon overwrites argv[0].

I don't think there is a relaible way to tell the system service daemonsfrom screen except for the name, and you'll want to detect screen-alikeprograms, too.

-- Top 100 things you don't want the sysadmin to say:40. The sprinkler system isn't supposed to leak is it?