bin owning files
Paul Traina
pst at comdesign.cdi.com
Thu Nov 17 05:47:28 AEST 1988
To reiterate past concerns briefly:
I'd like bin to own system executables, but I'm worried about
the fact that /bin is covered by /etc/hosts.equiv, so if a user
su'ed to bin on one machine, he could rlogin/rsh to another machine
and change anything owned by bin. The same sort of thing can
happen with remote-mounting the disk.
One solution was to have root own everything. This has drawbacks
which I won't reiterate.
Potential solution:
How about if we add a new 'first-character' to the password file
on a system. Currently we have '*' which sort-of signifies that
the userid is not loginable (has no password).
Could we add something like a '%' to the beginning of a password
field, which would then imply that /etc/hosts.equiv should not
be checked for rlogin/rsh (but of course ~/.rhosts could be), and/or,
if a filesystem is remotely mounted, any remote user-access comes
in as 'nobody' (just like root).
This way, we could protect accounts by adding a '%' to the start of the
password field. If this was used on certain sensitive "user" accounts too,
some mods to /bin/passwd and /bin/login would have to be made too, so that
pst:AZKjhjk38h$:332:51:Joe Luser:...
would become:
pst:%AZKjhjk38h$:... (and passwd & login would ignore the first char)
Comments? What are the drawbacks (other than in a NFS universe, where this
would be troublesome for "real" users as opposed to pseudo-users like bin and
sys)? This would seem to extend some of the protections provided to root to
any arbitrary user.
------
Paul Traina To believe that what is true for
{uunet|pyramid}!comdesign!pst you in your private heart is true
pst at cdi.com for all men, that is genius.
More information about the Comp.unix.wizards
mailing list