Subject: Re: xterm tty ownership (LFS)
To: None <tech-kern@netbsd.org>
From: Christos Zoulas <christos@astron.com>
List: tech-kern
Date: 09/14/2007 18:04:03
In article <200709140057.l8E0vtJh025845@wheel.duzan.org>,
Gary Duzan  <gary@duzan.org> wrote:
>   Picking up an old problem again, originally noted on current-users.
>
>In Message <200707050207.l6527Z4Y020784@wheel.duzan.org> ,
>   Gary Duzan <gary@duzan.org> wrote:
>
>=>In Message <20070704165625.3635856407@rebar.astron.com> ,
>=>   christos@zoulas.com (Christos Zoulas) wrote:
>=>
>=>=>
>=>=>I don'g get it then. The TIOCPTMGET should be doing the chown/chgrp/chmod
>=>=>for the pty, so that it ends up with the right permissions.
>=>
>=>   That's what I thought. I just updated to a new kernel without
>=>any debugging, and I get the same thing.
>
>   Here is the latest I have. I added VOP_PRINT before and after
>the call to VOP_SETATTR in sys/kern/tty_ptm.c:pty_grant_slave(),
>and get:
>
>==========================================================================
>tag VT_UFS, ino 494587, on dev 0, 0 flags 0x0, effnlink 1, nlink 1
>        mode 020666, owner 0, group 0, size 0 lock type vnlock: EXCL
>(count 1) by pid 462.1
>tag VT_UFS, ino 494587, on dev 0, 0 flags 0x2, effnlink 1, nlink 1
>        mode 020620, owner 100, group 4, size 0 lock type vnlock: EXCL
>(count 1) by pid 462.1
>==========================================================================
>
>   Looks ok to me. Nevertheless, the terminal reverts back to the
>original permissions, and I get this in the xterm:
>
>==========================================================================
>utmp_update: /dev/ttyp1: Is not owned by you
>capo { ~ } % tty
>/dev/ttyp1
>capo { ~ } % ls -li /dev/ttyp1
>494587 crw-rw-rw-  1 root  wheel  5, 1 Sep 13 20:40 /dev/ttyp1
>==========================================================================
>
>   The only thing I can think of as a cause is having an LFS /dev.
>Does this ioctl need to be a DIROP, perhaps? I wouldn't have thought
>so, but it is a weird problem.
>
>   Any ideas on what to try next? Thanks.

Add some debugging printfs to the lfs setattr for that particular inode, since
you know the number...

christos