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
Attachment:
pgpSSWeeesywv.pgp
Description: PGP signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
