On Sun, 20 Mar 2005, Rene Scharfe wrote:

> 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 asking
for the password agter the (m)ingetty got the username. These processes
are usurally created with the '-' sign in argv[0][0], but the users may
replace that string at will. I think it's still OK to depend on that if
you 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 daemons
from screen except for the name, and you'll want to detect screen-alike
programs, too.

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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to