Subject: Re: standards/19209: test(1)'s -r, -w, and -x don't match POSIX for root (or 4.4BSD, or even V7)
To: David Laight <firstname.lastname@example.org>
From: Greg A. Woods <email@example.com>
Date: 11/30/2002 16:34:26
[ 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. 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.
> Additionally you have to use access() in order to detect
> readonly file systems.
No, you don't. Please re-read again the text describing '-w' (and '-x')
which I've quoted twice now from IEEE POSIX 1003.2-1992.
> FWIW if a shell wants to know the file permission bits
> it can use $(stat -f '%p' file).
which standard is 'stat' in again?
A portable shell script can only use 'test' -- even one that requires a
specific 1003.2-1992 conformant runtime environment.
Greg A. Woods
+1 416 218-0098; <firstname.lastname@example.org>; <email@example.com>
Planix, Inc. <firstname.lastname@example.org>; VE3TCP; Secrets of the Weird <email@example.com>