🚀 go-pugleaf

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@cdi.com				for all men, that is genius.