Yuk! MIME!
Sorry about that....
Hm. Try changing fs/devfs/base.c:devfs_register() to use
current->fsuid instead of current->uid (and similarly for gid), and
recompile your kernel. I bet your xterm is using setfsuid(2) because
it still has root privileges.
Another test you can do is remove suid-root from the xterm binary. If
it's using Unix98 PTYs, I don't see why it needs root access anyway.
I will try this, but I wanted to let you know that xterm is _not_ suid.
konsole
is not, but another bin called 'konsole_grantpty' [hmm. wonder what
that could be
doing *jk*] IS suid. rxvt is not.
However, I don't know that much about KDE, etc. So I have
no idea what the init processes are doing. kde_init runs everything,
perhaps there are
some changes going on underneath?
Actually, devfs will wait for devfsd to finish processing an event.
Devfsd and all its children have special access to the filesystem. So
if you were to have an action which logged the permissions, and then
you have a PERMISSIONS action, the logging programme will see the
original permissions before they are changed by PERMISSIONS. However,
I don't think that is relevant to your problem.
I meant that I suppose that before devfsd started its work, devfs had
set the permissions. i.e.
current->uid
Before devfsd ran it's configuration.. I have not studied it all that
much..
Thanks for the tip!
joshua
|