pty_setowner and tty permissions

[Corinna Vinschen]

On Aug 28 03:27, Damien Miller wrote:
> On Wed, 27 Aug 2014, Corinna Vinschen wrote:
> 
> > Hi,
> > 
> > 
> > while looking into Cygwin's tty code, I stumbled over this problem:
> > 
> > Every time you log in to Cygwin via sshd, the pty's permissions are
> > set like this:
> > 
> >   $ ls -l `tty`
> >   crw--w--w- 1 user   group           136, 2 Aug 27 13:06 /dev/pty2
> > 
> > Since Cygwin sets the permissions more tight to begin with, I was
> > wondering why the permissions are this open.  Turns out, sshd sets
> > them like this:
> > 
> >   /* Determine the group to make the owner of the tty. */
> >   grp = getgrnam("tty");
> >   if (grp) {
> > 	  gid = grp->gr_gid;
> > 	  mode = S_IRUSR | S_IWUSR | S_IWGRP;
> >   } else {
> > 	  gid = pw->pw_gid;
> > 	  mode = S_IRUSR | S_IWUSR | S_IWGRP | S_IWOTH;
> >   }
> > 
> > On Windows no group called "tty" exists, so sshd always sets the
> > permissions to 0622 on Cygwin.
> > 
> > My question is, isn't that a security problem?  Shouldn't the
> > permissions set to 0600 if a "tty" group doesn't exist, otherwise
> > everyone can write to the user's tty?  What am I missing?
> 
> 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.


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/3bdcdb0e/attachment.bin>