Joshua M. Schmidlkofer writes:
> This is a multi-part message in MIME format.
Yuk! MIME!
> I am using UNIX98 PTY's, and using strictly devfs to manage the
> 'devpts'. [a.k.a. no devpts fs support in my kernel]. For some reason,
> under X I am experiencing a semi-random but frequent inability to start
> terms of any kind. I have been trying to narrow the problem down,
> however, I am not having good success. I added an event to devfsd that
> executed a script....:
>
> 'REGISTER pts/.* EXECUTE /bin/logperms.sh'
> 'UNREGISTER pts/.* EXECUTE /bin/logperms.sh'
>
> And I found that the files are being created w/incorrect
> ownership. I started parsing through kernel code, examining
> char/pty.c, char/tty_io.c, and devfs/base.c. I can follow the path
> of execution, but I fail to see where the ownership could be
> mistaken. As I started to try and read it, it came upon me that I
> was going to have to learn about process management in the
> kernel. This seems a bit of a steep climb from the hole that I am
> in. [esp. when I can't open any new terminal. *laugh*].
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.
> Here are the symptoms:
>
> _SOMETIMES_ terminals will start properly, and when they do, I will
> be able to open 5 or 6 or maybe even 10, but eventually the system
> will halt opening new terminals. If I try to open a new one, then it
> immediatly dies. If I start it from within an open one [i.e. rxvt&]
> I get a message: 'unable to open slave pty'. I read through rxvt to
> that point, and the code indicates that an open of /dev/pts/[??]
> failed. Using the REGISTER event, I was able to see that the device
> had an improper ownership. Further examination of the code SEEMED to
> indicate that devfs _should_ have the device properly set before
> notifying devfsd....
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.
Anyway, I'm on holidays, so don't expect speedy followup
responses. Good luck, and please let me know how it goes.
Regards,
Richard....
Permanent: rgooch@xxxxxxxxxxxxx
Current: rgooch@xxxxxxxxxxxxxxx
|