Xref: utzoo comp.bugs.4bsd:1080 comp.unix.wizards:12486 Path: utzoo!attcan!uunet!comdesign!pst From: pst@comdesign.cdi.com (Paul Traina) Newsgroups: comp.bugs.4bsd,comp.unix.wizards Subject: bin owning files Keywords: bin, root, /etc/hosts.equiv Message-ID: <566@comdesign.CDI.COM> Date: 16 Nov 88 19:47:28 GMT Sender: news@comdesign.CDI.COM Lines: 39 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.