Date: Fri, 30 Mar 2012 13:35:42 -0700 From: Alfred Perlstein <alfred@freebsd.org> To: "Julian H. Stacey" <jhs@berklix.com> Cc: arch@freebsd.org, Adrian Chadd <adrian@freebsd.org> Subject: Re: Should standard binaries & directories revert from uid=root to bin ? Message-ID: <20120330203542.GV36229@elvis.mu.org> In-Reply-To: <201203302016.q2UKGMHP016165@fire.js.berklix.net> References: <CAJ-Vmon=YKcW6Osn2TXcJDbNH1B0xLapL-fTz0myGanHdPW4Yw@mail.gmail.com> <201203302016.q2UKGMHP016165@fire.js.berklix.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[[ Top post replying just for lols. ]] Julian, please read up on how maproot works with NFS. I think Adrian's paranoia trumps your convenience, but I'm open to being convinced otherwise. -Alfred * Julian H. Stacey <jhs@berklix.com> [120330 13:17] wrote: > Hi Adrian & arch@ > Please don't top post to arch@freebsd.org > Please don't emit messy quoted-printable hex. '\xa0' for clean spaces. > > Adrian Chadd wrote: > > hi, > > > > because id=0 defaults to being squashed via nfs. > > Not a sentence. Please clarify. > > > > But if you have a > > filesystem full of uid=bin/gid=bin binaries, a slightly insecure NFS > > setup would allow NFS clients to simply set their uid=bin and change > > these binaries. :-) > > I don't understand your meaning. I do understand SUID though. > Please clarify whay you mean. > > Do you mean if something like /usr/sbin/lpd was uid=bin on one > system, it might slip via a bad NFS to be seen as UID=0 on another ? > & remotely excutable on 2nd system as a UID=0 ? > If that's what you mean, bear in mind /usr/sbin/lpd is currently already > uid=0. Also bear in mind NFS man exports -maproot > > Are you stating? or just speculating ? if [flakey?] NFS was the > reason FreeBSD changed from bin to root ? > > I hadn't considered NFS lax security when I asked the question. > (I had merely mentioned NFS in context of explaining how I > (re-)noticed the wholesale conversion from bin to root. > > It's possible NFS might have been a reason ? > but I don't see you made an explanation [yet] as to how > a return from root to bin would be dangerous with a flakey NFS ? > > Not that I'm saying it would/ wouldn't be an issue, > I am just asking why we changed, & if a move back would be good ? > As I see one loss from the change. > There may have been other issues though ? Anyone know ? > > > > On 30 March 2012 08:16, Julian H. Stacey <jhs@berklix.com> wrote: > > > Hi arch@ > > > Time was, (& I can go back over 25 years here, but more recently too :-) > > > When standard Unix non SUID executables such as wc would be UID=bin, > > > GID=bin, & not root. Ditto bin/ & lib/ etc directories. > > > > > > One advantage was: > > > Anything that showed up with ls -l as UID=0 was either a SUID > > > special, known to the admin's eye, or some administrative dropping, > > > mistakenly created by someone logged in as root, to be reviewed/ > > > regenerated/ deleted. > > > > > > Now all is UID=0. Why ? What advantage did it bring ? > > > > > > Obviously some SUID & SGID executables need 0 (some could need just bin!) > > > but most files & directories do not need UID 0. > > > > > > BTW, How I noticed this : > > > I was tracing why > > > /usr/sbin/sshd -d -d -d -D > > > was erroring: > > > debug3: secure_filename: checking '/.amd_mnt/sshd_host/ad4s1/usr1/home' > > > Authentication refused: bad ownership or modes for directory > > > /.amd_mnt/sshd_host/ad4s1/usr1/home > > > just because my ~/.ssh was symbolicaly linked via AMD+NFS mounted on another > > > host, & there an intermediate directory was owned by bin & not root, > > > ls -la /host/sshd_host/ad4s1/usr1/home > > > drwxr-xr-x 18 bin bin 512 Mar 6 11:56 ./ > > > so I had to > > > chown root:wheel /ad4s1/usr1/home > > > Just to satisfy sshd being pointlessly strict, as directory was 755. > > > > > > So we have sshd that's pointlessly strict, & ownerships that seem > > > to have near all lost their precision. A funny combo ;-) > > > > > > Might others tackle the generic over use of root ? > > > If so I could create a patch to send-pr ssh ? > > > (but as ssh is an import, maybe just report & not [yet?] patch ?) > > > > > > Cheers, > > > Julian > > > -- > > > Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklixcom > > > Reply below not above, cumulative like a play script, & indent with "> ". > > > Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. > > > Mail from @yahoo dumped @berklix. http://berklix.org/yahoo/ > > > _______________________________________________ > > > freebsd-arch@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > > > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > > _______________________________________________ > > freebsd-arch@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > > > > > > > Cheers, > Julian > -- > Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com > Reply below not above, cumulative like a play script, & indent with "> ". > Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. > Mail from @yahoo dumped @berklix. http://berklix.org/yahoo/ > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" -- - Alfred Perlstein .- VMOA #5191, 03 vmax, 92 gs500, 85 ch250, 07 zx10 .- FreeBSD committer
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120330203542.GV36229>