SemiOT: filePro on FreeBSD chown gotcha

[Fairlight]

Is it just me, or did Jay Ashworth say:
> On Tue, Jun 22, 2004 at 12:04:13PM -0400, Walter Vaughan wrote:
> > <quote>
> > The ownership of a file may only be altered by a super-user for obvious
> > security reasons.
> > </quote>
> 
> Yeah, right.
> 
> It's for "university students can't avoid file quotas" reasons.

Agreed.  Whether someone considers quotas part of the security subsystem is
a questionable point.  Some might consider workarounds to exceed quotas
"unauthorised use".


> Nope; you're screwed.  BSD-ish systems, which include Linux, but not
> SCO, constrain chown(2) in that fashion; Linux-ABI commonly correctly
> emulates the SCO behaviour, although I'm having a showstopper problem
> with that on SUSE 9 right now: a kernel upgrade apparently broke *that
> part* of the ABI; older 9.0 installs work ok.

Hate to tell you, but Solaris 7 and 8 both constrain chown() as well.  By
default anyway.  But the following may help anyone on Solaris, and may also
give everyone else a basis to scour their own platforms for an equivalent:

     The  operating  system  provides  a  configuration   option,
     {_POSIX_CHOWN_RESTRICTED}, to restrict ownership changes for
     the   chown(),  lchown(),  and   fchown()  functions.   When
     {_POSIX_CHOWN_RESTRICTED}  is  not  in  effect,  either  the
     effective user ID of the process must match the owner of the
     file  or  the  process  must be the super-user to change the
     ownership of a file. When  {_POSIX_CHOWN_RESTRICTED}  is  in
     effect  (the  default  behavior), the chown(), lchown(), and
     fchown() functions, for users other than super-user, prevent
     the  owner  of  the  file from changing the owner ID  of the
     file and restrict the change of the group of the file to the
     list  of  supplementary group IDs. To set this configuration
     option, include the following line in /etc/system:

          set rstchown = 1

Looks like the behaviour is part of one of the POSIX standards.  It doesn't
surprise me that linux would honour it, in this event.  But it -may- be
configurable, as well.  I highly doubt it would be configurable in the same
way.  It might need a recompile of libc itself.  The reason I say this is a
cursory glance at the RH 7.3 chown(2) man page:

       The chown call conforms to SVr4, SVID, POSIX, X/OPEN.  The
       4.4BSD version can only be used by the superuser (that is,
       ordinary  users  cannot  give away files).  SVr4 documents
       EINVAL, EINTR,  ENOLINK  and  EMULTIHOP  returns,  but  no
       ENOMEM.   POSIX.1  does not document ENOMEM or ELOOP error
       conditions.

This implies to me that it's configurable if you compile it non-BSD-style.

mark->
-- 
Bring the web-enabling power of OneGate to -your- filePro applications today!

Try the live filePro-based, OneGate-enabled demo at the following URL:
               http://www2.onnik.com/~fairlite/flfssindex.html