Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!mcsun!ukc!edcastle!aiai!richard From: richard@aiai.ed.ac.uk (Richard Tobin) Newsgroups: comp.protocols.nfs Subject: Re: group permissions when root Message-ID: <4996@skye.ed.ac.uk> Date: 24 Jun 91 18:53:47 GMT References: <15008@exodus.Eng.Sun.COM> <6720@eastapps.East.Sun.COM> <4978@skye.ed.ac.uk> <7958@spdcc.SPDCC.COM> Reply-To: richard@aiai.UUCP (Richard Tobin) Organization: AIAI, University of Edinburgh, Scotland Lines: 37 In article <7958@spdcc.SPDCC.COM> rbraun@spdcc.COM (Rich Braun) writes: >richard@aiai.UUCP (Richard Tobin) writes: >>For the same reason that you trust a non-root uid that root gives >>itself. >You're overlooking one thing: if you have two systems A and B, and >a root user on B su's to some other uid, he now has access to files on >system A under that new uid. I wasn't overlooking it; it was the point of my posting. Given that root can gain access to any other user's files in this way, there's no point not trusting root's groups. As I've commented before, this also means it's pointless to not let root just go ahead and access files that any non-root local user could access. The only thing it really prevents is a remote root doing things that only root could do locally. This misfeature, coupled with stupid client caching, leads to this persistent annoyance, which is still in SunOS 4.1.1: skye# ls -l xyz -rw------- 1 richard 6 Jun 24 19:47 xyz [xyz is on a remote file system] skye# cat xyz cat: write error: Permission denied [this error message is of course another bug] skye% cat xyz cat: write error: Permission denied [and now I can't read my own file!] -- Richard -- Richard Tobin, JANET: R.Tobin@uk.ac.ed AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin