pty_setowner and tty permissions

Corinna Vinschen vinschen at redhat.com
Thu Aug 28 07:41:56 EST 2014


On Aug 28 07:07, Damien Miller wrote:
> On Wed, 27 Aug 2014, Corinna Vinschen wrote:
> 
> > > I think the intention was to allow tools like wall(1) and write(1)
> > > to function on systems without a "tty" group, but IMO it's better
> > > to let the admin decide that.
> > 
> > What does that mean for the existing code?  How can we empower the admin
> > to decide it?  The current code only lets the admin decide to invent a
> > "tty" group to get tighter permissions, but that won't work in
> > environments with account naming rules.  Even worse, since that
> > dependency on the "tty" group name is hidden in source code, it's not
> > clear to admins how to handle this scenario.
> 
> by deleting the code that alters the tty mode based on the presence
> of the group and letting them either a) add it themselves or b) arrange
> for the tty permissions to be changed as part of the login process.
> 
> Many systems do (b) already for a bunch of stuff in /dev so it isn't
> irrational.

Your code change makes sense to me, albeit I'm wondering if the default
permission on "tty"-less systems shouldn't be 0600.  Consider that the
default group for users is often something along the lines of the
"users" group.  On Windows it's the "Domain Users" group, or its local
machine equivalent.  In most environments that means that *all* users
will be allowed to write to your tty since it's rather uncommon to
change the primary group on Windows.

Apart from that I'm probably a bit dense but I'm puzzled about your
points a and b:

a) Add what themselves?  A "tty" group?  If the system doesn't provide
   one by default, there's probably not much sense to add it.

b) How would an admin be able to influence the tty permissions as part
   of the login process?  If sshd starts the user shell, where is the
   point the admin can intervene?
  

Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20140827/4c6e78a5/attachment.bin>


More information about the openssh-unix-dev mailing list