public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: jw schultz <jw@pegasys.ws>
To: linux-kernel@vger.kernel.org
Subject: Re: suid bit on directories
Date: Sat, 18 May 2002 18:12:57 -0700	[thread overview]
Message-ID: <20020518181257.Y840@pegasys.ws> (raw)
In-Reply-To: <20020518103432.5a3b4c67.michael@hostsharing.net> <20020518105252.A3897@enst.fr> <20020518123435.6905c1e0.michael@hostsharing.net>

On Sat, May 18, 2002 at 12:34:35PM +0200, Michael Hoennig wrote:
> Hi Cedric,
> 
> > > I do not even see a security hole if nobody other than the user itself
> > > and httpd/web can reach this area in the file system, anyway. And it
> > > is still the users decision that files in this (his) directory should
> > > belong to him.
> > 
> > I guess it is considered a security hole if a user can create files not
> > belonging to him.
> 
> where is it so much different from the guid flat on directories?  That way
> too, you could get rights of a group of which you are not a member.  As

You don't get the rights of the group.  This only allows the
file/directory you could have created anyway to be created with the
gid of the parent.  And you still are the owner so it can be
seen who is responsible for it existing.

The only possible way non-members could do this would be if
the directory has dangerous^Wrisky permissions allowing non-group
members to write in it.

I use sgid directories frequently.  Usually with
user-private-groups and umask of 002. It keeps lusers from
misusing chmod.

> far as I can see, all what has to be prevented, is to create files with
> suid flag set within such a folder - not even for a microsecond

_Please_ don't describe it this way.  We don't want any
files any time to be created with suid flag set
automatically.  Describe it as "the suid flag set _on_ the
directory" or "suid directory", etc.

> (race-condition).  Or do I miss something?  Other issues are quota, but
> this problem already exists with guid bit for directories.  And in my case
> (mod_php), it is even worse the way it is.

Group quotas are used even less than user quotas so i don't
consider them much of an issue (someone else probably does).
What i do consider an issue is user accountability.  There
are reasons besides quota only root can chown.

You haven't articulated how doing this would be of benefit to
anyone.  Leaving that aside you could work up a patch to
allow this behaviour.

Features would be:

	1 a non-default mount option. 

	2 either incompatible with quota or throwing up
 	  warnings if quota is enabled.

	3 ineffective if the directory is also sticky.

Personally i don't care for the idea but, hey, you can try.
As long as it doesn't become a default it won't affect me.


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

		Remember Cernan and Schmitt

  reply	other threads:[~2002-05-19  1:13 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-05-18  8:34 suid bit on directories Michael Hoennig
2002-05-18  8:52 ` Cedric Ware
2002-05-18 10:34   ` Michael Hoennig
2002-05-19  1:12     ` jw schultz [this message]
2002-05-20 13:04 ` Jesse Pollard
2002-05-20 13:24   ` Michael Hoennig
2002-05-20 14:03     ` Jesse Pollard
2002-05-20 14:53       ` Michael Hoennig
2002-05-20 18:12         ` dean gaudet
2002-05-21 17:48           ` Bill Davidsen
2002-05-20 19:28         ` Jesse Pollard
2002-05-20 20:58           ` Miquel van Smoorenburg
2002-05-20 21:15           ` Michael Hoennig
2002-05-21 18:03             ` Bill Davidsen
2002-05-22  4:44               ` Michael Hoennig
2002-05-21  3:49           ` Dax Kelson
2002-05-20 15:53       ` Bill Davidsen
2002-05-20 19:17       ` Albert D. Cahalan
2002-05-20 20:17         ` Jesse Pollard
2002-05-21  3:28       ` Dax Kelson
2002-05-21  3:58         ` Dax Kelson
2002-05-21 18:04           ` Bill Davidsen
2002-05-21 18:35             ` J Sloan
2002-05-20 15:42   ` Bill Davidsen
  -- strict thread matches above, loose matches on Subject: below --
2002-05-21 13:34 Jesse Pollard
2002-05-21 13:34 Jesse Pollard

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=20020518181257.Y840@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