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.
Index: sshpty.c
===================================================================
RCS file: /var/cvs/openssh/sshpty.c,v
retrieving revision 1.47
diff -u -p -r1.47 sshpty.c
--- sshpty.c 21 May 2014 07:06:47 -0000 1.47
+++ sshpty.c 27 Aug 2014 21:07:22 -0000
@@ -191,18 +191,12 @@ pty_setowner(struct passwd *pw, const ch
{
struct group *grp;
gid_t gid;
- mode_t mode;
+ mode_t mode = S_IRUSR | S_IWUSR | S_IWGRP;
struct stat st;
/* 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;
- }
+ gid = (grp != NULL) ? grp->gr_gid : pw->pw_gid;
/*
* Change owner and mode of the tty as required.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
