SemiOT: filePro on FreeBSD chown gotcha

[Jay R. Ashworth]

On Tue, Jun 22, 2004 at 12:57:02PM -0400, Fairlight wrote:
> 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.

Did you have the impression I'd be surprised?  Polaris is BSD-based.

>                                                                        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. 

They stole it from BSD.  Nice to know Polaris has a knob, at least.

>                                                                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.

That's the ugliest, least useful manpage I've *ever* seen.

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

Compile *what*?  libc6?

Ick.

If it ain't a runtime knob, it doesn't help me much...

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra at baylink.com
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274

                2004 Stanley Cup Champion Tampa Bay Lightning