[2244] in SIPB bug reports
Re: xscreensaver permissions?
daemon@ATHENA.MIT.EDU (mhpower@Athena.MIT.EDU)
Sat Nov 9 23:19:23 1991
From: mhpower@Athena.MIT.EDU
To: eichin@Athena.MIT.EDU
Cc: bug-sipb@Athena.MIT.EDU
In-Reply-To: [2243] in SIPB bug reports
Date: Sat, 09 Nov 91 23:18:12 EST
> ... xscreensaver on the
>rs6k; it seems that it needs to be setgid security, which is group
>7... I've changed it, but I haven't released the volume since noone is
>around to test it.
>
>portnoy#% ls -l xscreensaver
>-rwxr-sr-x 1 jik #7 438605 Nov 6 13:14 xscreensaver*
It's not clear to me that there should be any setgid or setuid
programs in the sipb fileset. If I understand things correctly,
achieving such permissions in the Athena-cell copy of the fileset
requires intervention by a member of system:administrators for the
Athena cell.
I realize that, currently, some of these persons are SIPB members, and
those that aren't SIPB members might be willing to help us out by
setting the permissions we request. In general, though, I don't think
we should rely on such requests being quickly or routinely granted
into the indefinite future. If we want an up-to-date backup copy of
the sipb fileset in a "foreign" AFS cell, I believe we should not have
setgid or setuid programs, at all. This should make software
maintenance easier, and, more importantly, place the sipb fileset more
directly under the control of (a reasonably sized subset of active)
SIPB members.
Rejecting setgid/setuid software is also of benefit to users who learn
about application programming by reading source code in sipbsrc and
trying various modifications of their own: they'll always be able to
install working versions in their own homedirs. Finally, without
setgid/setuid permissions, SIPB software could not be at fault in a
case of unauthorized privileged access to a multi-user or private
workstation.
In the case of xscreensaver, I understand that there may be an minor
inconvenience if it is not setgid or setuid, but I don't think it is
intolerable. If the only problem is that encrypted passwords are not
readable on the workstation's local disk, then the user should be
specifying a password in some other manner, e.g., by using the -ekey
option or the XScreensaver.encryptedKey resource. This may motivate
some users to choose more secure passwords.
A better solution, if acceptable to DCNS, would be to configure public
RS/6000 workstations to have more liberal permissions on all of
/etc/security, as part of the next Athena release for the RS/6000.
Matt
P.S., on the one RS/6000 I checked, /etc/security/passwd was mode 600,
owned by root, so perhaps setuid root would be preferable to setgid
security?
