public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: jw schultz <jw@pegasys.ws>
To: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [2.5.73-mm1 XFS] restrict_chown and quotas
Date: Wed, 25 Jun 2003 19:00:40 -0700	[thread overview]
Message-ID: <20030626020039.GD11555@pegasys.ws> (raw)
In-Reply-To: <1056554727.1174.86.camel@laptop.americas.sgi.com>

On Wed, Jun 25, 2003 at 10:25:26AM -0500, Steve Lord wrote:
> On Wed, 2003-06-25 at 10:16, Christoph Hellwig wrote:
> > On Wed, Jun 25, 2003 at 10:11:40AM -0500, Steve Lord wrote:
> > > This is all backwards compatibility with folks expecting Irix behavior,
> > > and I think on Irix it is even a backwards compatibility thing. If we
> > > were not having a major power outage at work right now I could look
> > > at Irix and confirm this. Imposing different semantics on the rest of
> > > the filesystems did not seem like the right thing to do.
> > 
> > Actually there's a posix option group for finding out exactly that,
> > (see http://people.redhat.com/drepper/posix-option-groups.html#CHOWN_RESTRICTED)
> > but yeah it might be more of a legacy thing.
> > 
> > Adding a common sysctl for this would allow glibc to properly implement
> > patchconf(..., _PC_CHOWN_RESTRICTED), but it seems SuSv2/3 sais it must
> > be always defined:
> > 
> > http://www.opengroup.org/onlinepubs/007908799/xsh/chown.html
> 
> Thanks, I also found out that the unrestricted  chown behavior is the
> way AT&T system V did it originally. I vote for this being a legacy
> thing.

That is correct.  It had some utility when a process could
only be a member of one group at a time and for giving files
to someone else while keeping all others out.  Chown was
expected to disable s[ug]id bits.  The value of an
unrestricted chown is very small and will be eliminated by
ACLs.

Quotas turned it into a security issue.   With unrestricted
chown a user could chown large files to another (preferably
unlimited) uid and avoid the limits and usage charges.  It
also allows one user to sabotage another by causing that
user to go over quota on files he has no knowledge or control
over.  Quotas and unrestricted chown do not mix.

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw@pegasys.ws

		Remember Cernan and Schmitt

  reply	other threads:[~2003-06-26  1:50 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-25  9:51 [2.5.73-mm1 XFS] restrict_chown and quotas Marek Habersack
2003-06-25 12:51 ` Steve Lord
2003-06-25 13:41   ` Marek Habersack
2003-06-25 14:25     ` Arjan van de Ven
2003-06-25 14:35       ` Christoph Hellwig
2003-06-25 15:11         ` Steve Lord
2003-06-25 15:16           ` Christoph Hellwig
2003-06-25 15:25             ` Steve Lord
2003-06-26  2:00               ` jw schultz [this message]
2003-06-25 15:39             ` Marek Habersack
2003-06-25 15:56               ` Christoph Hellwig
2003-06-25 15:11     ` Valdis.Kletnieks
2003-06-25 15:46       ` Marek Habersack

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030626020039.GD11555@pegasys.ws \
    --to=jw@pegasys.ws \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox