From: Elladan <elladan@eskimo.com>
To: Alexander Viro <viro@math.psu.edu>
Cc: Elladan <elladan@eskimo.com>,
Jakob ?stergaard <jakob@unthought.net>,
Kasper Dupont <kasperd@daimi.au.dk>,
Linux-Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] ext2 and ext3 block reservations can be bypassed
Date: Sun, 12 May 2002 11:37:30 -0700 [thread overview]
Message-ID: <20020512113730.A24085@eskimo.com> (raw)
In-Reply-To: <20020512103432.A24018@eskimo.com> <Pine.GSO.4.21.0205121412160.25791-100000@weyl.math.psu.edu>
On Sun, May 12, 2002 at 02:15:12PM -0400, Alexander Viro wrote:
>
> On Sun, 12 May 2002, Elladan wrote:
> >
> > It just happens that the suid program wasn't the one who chose what file
> > it was going to write stdout to - the shell did.
> >
> > Thus, the security violation.
>
> <shrug> relying on 5% in security-sensitive setup is *dumb*.
> In that case you need properly set quota (better yet, no lusers with write
> access anywhere on that fs)..
>
> There are worse holes problems 5% rule. E.g. you can create a
> file with hole, mmap over that hole, dirty the pages and exit. Guess
> who ends up writing them out? Right, kswapd. Which is run as root.
> No suid applications required...
Regardless of whether it's a good thing to depend on security-wise, it
is a problem to have something that appears to be a security feature
which doesn't actually work.
Reading the documentation, I would expect that if I create an ext3
filesystem, reserve 20% of it for root, and then run a cron job as root
that uses 16% of that filesystem periodically, that cron job will not
actually fail whenever some luser decides they want it to.
I don't recall seeing it plastered in huge letters, "This space reserve
is just a convenience feature, and can easily be circumvented by the
user. You must never rely on it for anything."
Having unsupported security features is typically a bad idea.
-J
next prev parent reply other threads:[~2002-05-12 18:38 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-12 16:23 [RFC] ext2 and ext3 block reservations can be bypassed Kasper Dupont
2002-05-12 16:42 ` Jakob Østergaard
2002-05-12 17:34 ` Elladan
2002-05-12 18:15 ` Alexander Viro
2002-05-12 18:37 ` Elladan [this message]
2002-05-12 19:02 ` Jakob Østergaard
2002-05-12 19:04 ` Mark Mielke
2002-05-13 17:09 ` Horst von Brand
2002-05-13 17:52 ` Elladan
2002-05-13 17:57 ` Christoph Hellwig
2002-05-14 16:22 ` Elladan
2002-05-14 16:55 ` Mark Mielke
2002-05-14 17:47 ` Elladan
2002-05-14 18:51 ` Kasper Dupont
2002-05-15 19:48 ` Pavel Machek
2002-05-15 20:29 ` Alan Cox
2002-05-14 15:40 ` Kasper Dupont
2002-05-14 15:56 ` Mark Mielke
2002-05-14 18:25 ` Kasper Dupont
[not found] <791836807@toto.iv>
2002-05-12 22:04 ` Peter Chubb
2002-05-12 22:53 ` Alexander Viro
2002-05-13 4:22 ` Kasper Dupont
2002-05-13 4:51 ` Elladan
-- strict thread matches above, loose matches on Subject: below --
2002-05-14 17:53 Jesse Pollard
2002-05-14 18:23 ` Mark Mielke
2002-05-14 19:11 ` Alexander Viro
2002-05-14 18:00 Jesse Pollard
2002-05-14 18:07 Jesse Pollard
2002-05-14 18:54 Jesse Pollard
2002-05-14 19:04 ` Alexander Viro
2002-05-14 19:55 ` Mark Mielke
2002-05-14 19:29 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=20020512113730.A24085@eskimo.com \
--to=elladan@eskimo.com \
--cc=jakob@unthought.net \
--cc=kasperd@daimi.au.dk \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@math.psu.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.