[ On Sunday, December 1, 2002 at 20:02:11 (+0000), David Laight wrote: ]
> Subject: Re: standards/19209: test(1)'s -r, -w, and -x don't match POSIX for root (or 4.4BSD, or even V7)
>
> On Sat, Nov 30, 2002 at 04:34:26PM -0500, Greg A. Woods wrote:
> > [ On Saturday, November 30, 2002 at 10:17:20 (+0000), David Laight wrote: ]
> > > Subject: Re: standards/19209: test(1)'s -r, -w, and -x don't match POSIX for root (or 4.4BSD, or even V7)
> > >
> > > > > + 	euid = geteuid();
> > > > > + 	if (euid == 0)
> > > > 
> > > > I don't think userspace ought to be checking for 'appropriate
> > > > privileges' by checking uid == 0.  It is currently true for
> > > > netbsd but isn't portably true.
> > > 
> > > It isn't true for NFS!
> > 
> > What does NFS have to do with the privileges of a program running on a
> > given host?  Just because you're "root" on some host doesn't mean you'll
> > be "root" on some other NFS server.
> 
> My point exactly! So the test program cannot use the euid to determine
> whether you have 'appropriate privileges' to access the file in question.

but that's not what POSIX says 'test' should be reporting.....

> Your version of test will incorrectly say that root has permission
> when in fact it does not.

Yes, because this is is exactly what it should do, as per POSIX.

> > Except for a few very special cases
> > the effect of root accesses to an NFS volume that's exported with client
> > UID==0 mapped to UID=-2 (or whatever) is effectively the same, from
> > 'test's point of view, as it is for filesystems mounted read-only.  Test
> > does not, and should not, care about the filesystem mount options here.
> 
> The posix spec explicitly states that a test -w should fail if
> the filesystem is mounted readonly.

Ah, no, it does not.  Here it is again:

    -w file      True if file exists and is writable.  True shall indicate
                 only that the write flag is on.  The file shall not be
                 writable on a read-only file system even if this test
                 indicates true.

It's trivial to find out if a script running as root (or any other user,
for that matter) can actually write to, or read from, a file or not.
The intent here is to find out what the permissions bits are without
having to use non standard utilities and without having to parse the
output of 'ls -l'.

This intent is made much more clear when it comes to 'execute'
permission.  One obviously does not wish to try to execute a program
just to find out what the state the relevant execute bits are in.  I
believe, though there's no rationale given to confirm, that's why the
POSIX wording was clarified over the original SVID wording in the first
place:

    -x file      True if file exists and is executable.  True shall
                 indicate only that the execute flag is on.  If file is a
                 directory, true indicates that file can be searched.

It only follows that '-w' and '-r' must behave the same way.
Unfortunately for all concerned only the '-w' wording was clarified, and
no rationale was given for why '-r' was left alone, however even the
PASC interpretation of this issue makes it quite clear that it's OK for
an implementation to do '-r' in the same way as '-w' and '-x', as in
"any behaviour is allowed":

 IEEE Interpretation for 1003.2-1992                                            
 -----------------------------------                                            
                                                                                
 The standard does not state that -r checks the read bit, so it does not        
 have that restriction the way the -w and -x flags do.  The question of         
 which flags are checked (and the order) is unspecified by the standard,        
 and thus any behavior is allowed.  Concern over the wording of this            
 section of the standard has been forwarded to the sponsors of the              
 standard.                                                                      
                                                                                
 Rationale for Interpretation:                                                  
 -----------------------------                                                  
 None.                                                                          


-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>