Re: UFS and POSIX test suite

["Valeriy E. Ushakov" <uwe%stderr.spb.ru@localhost>]

On Sun, Jan 01, 2012 at 18:12:48 +0000, Roland C. Dowdeswell wrote:

> On Sun, Jan 01, 2012 at 07:05:06PM +0100, Emmanuel Dreyfus wrote:
> >
> 
> > I intentend to use it to hunt bugs for NetBSD FUSE. Without any
> > surprise, there are a lot of failures, but I am a it surprised to see
> > that NetBSD UFS fails the same tests most of the time.
> > 
> > To give an exaample, the script detects that when an unprivilegied user
> > attempts to set the setGID bit, it should be cleared, while NetBSD UFS
> > returns EPERM.
> > 
> > And just clearing the bit indeed seems to be mandated by POSIX:
> >  http://pubs.opengroup.org/onlinepubs/7908799/xsh/chmod.html)
> > 
> > Opinions? Do we have bugs to fix here? Anyone already gave it a try?
> 
> It seems to me that either behaviour complies with the language
> that you quote:
> 
>       If the calling process does not have appropriate privileges,
>       and if the group ID of the file does not match the effective
>       group ID or one of the supplementary group IDs and if the
>       file is a regular file, bit S_ISGID (set-group-ID on
>       execution) in the file's mode will be cleared upon successful
>       return from chmod().
> 
> This does not specify that the call to chmod(2) return success if
> an unprivileged user attempts to set the setGID but it does specify
> that if success is returned then the bit should be cleared, if I
> am reading it correctly.  This seems to indicate that both behaviours
> are valid.

Hmm, on a cursory reading EPERM seems the only correct behaviour.
chmod is permitted if

  effective user ID of the process must match the owner of the file or
  the process must have appropriate privileges

otherwise:

  [EPERM]
    The effective user ID does not match the owner of the file and the
    process does not have appropriate privileges.

is returned.  So unless "unprivileged script" in Emmanuels mail means
something special, we correctly return EPERM.


The quoted passage about S_ISGID seems to tell that if user does own
the file (cf. "successful return from chmod()") but there is gid
mismatch, then S_ISGID in "mode" is silently ignored if present and is
also "cleared ...  in the file's mode" - but chmod() still succeeds.

-uwe