mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jakob Lell <jlell@JakobLell.de>
To: Jan Kara <jack@suse.cz>, Jamie Lokier <jamie@shareable.org>
Cc: "Richard B. Johnson" <root@chaos.analogic.com>,
	linux-kernel@vger.kernel.org
Subject: Re: hard links create local DoS vulnerability and security problems
Date: Tue, 25 Nov 2003 16:27:04 +0100	[thread overview]
Message-ID: <200311251627.04335.jlell@JakobLell.de> (raw)
In-Reply-To: <20031125144847.GA6748@atrey.karlin.mff.cuni.cz>

On Tuesday 25 November 2003 15:48, Jan Kara wrote:
> > Richard B. Johnson wrote:
> > > To prevent this, a user can set his default permissions so that
> > > neither group nor world can read the files. This is usually done
> > > by setting the attributes in the user's top directory.
> >
> > Correct, but the quota problem is genuine: what if I want to create a
> > lot of files in /home/jamie that are readable by other users, but I
> > want to be able to delete them at some later time and reuse my quota
> > for something else?
> >
> > This is quite a normal scenario on multi-user systems with quotas.
> >
> > You seem to be suggesting that the only method is to have a separate
> > partition for each user, which is absurd.
>
>   I agree that malicious user can make some user run out of quotas
> (actually he can do it even by more secret way by just opening the files
> - but for this at least read permission is needed). But I guess that
> reasonably capable admin discovers the problem and /bin/nologin as a
> login shell solves the problem...
Hello,
if it's a web server with thousands of users (and maybe millions of files 
in  /home), searching /home for files belonging to one user can take quite 
long (maybe hours). 
If the evil users can't create hard links and thus has to keep the file open 
instead of creating a hard link, the problem can quickly be found using lsof.
>
> > Another method is "tree quotas" which have come up on this list
> > before.  Hopefully they will be included one day; tree quotas seem
> > like they would solve this problem and some others.
>
>   Yes they would but denying hardlinks across 'quota trees' seems to be
> the easiest way of making them technically possible and so you end up in
> a similar situation as with some security patches...

This would also be a good way to fix the problem.
>
> 								Honza

Regards
  Jakob


  reply	other threads:[~2003-11-25 15:24 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-24 16:36 Jakob Lell
2003-11-24 17:05 ` Måns Rullgård
2003-11-24 20:42   ` Mike Fedyk
2003-11-24 17:14 ` Richard B. Johnson
2003-11-24 17:35   ` Jamie Lokier
2003-11-24 18:57     ` aic7xxx loading oops in 2.6.0-test10 Alexander Nyberg
2003-11-24 20:03       ` Ken Witherow
     [not found]         ` <Pine.LNX.4.58.0311241524310.1245@morpheus>
2003-11-24 20:49           ` Ken Witherow
2003-11-24 23:42             ` Dick Streefland
2003-11-25  3:16     ` hard links create local DoS vulnerability and security problems Matthias Andree
2003-11-25 14:48     ` Jan Kara
2003-11-25 15:27       ` Jakob Lell [this message]
2003-11-24 17:37   ` Rudo Thomas
2003-11-24 18:10     ` Richard B. Johnson
2003-11-24 18:22       ` Valdis.Kletnieks
2003-11-24 22:17       ` [OT] " Rudo Thomas
2003-11-24 17:57   ` Jakob Lell
2003-11-24 18:08     ` splite
2003-11-24 18:13       ` Richard B. Johnson
2003-11-24 18:24         ` Jakob Lell
2003-11-24 23:57         ` bill davidsen
2003-11-24 18:18       ` Jakob Lell
2003-11-24 18:29         ` Valdis.Kletnieks
2003-11-24 19:25           ` hard links create local DoS vulnerability and security proble Mathieu Chouquet-Stringer
2003-11-24 20:00             ` Valdis.Kletnieks
2003-11-24 20:02               ` Mathieu Chouquet-Stringer
2003-11-24 20:22             ` H. Peter Anvin
2003-11-24 18:21     ` hard links create local DoS vulnerability and security problems Michael Buesch
2003-11-24 18:35       ` Jakob Lell
2003-11-24 18:53       ` Chris Wright
2003-11-25  0:04         ` bill davidsen
2003-11-25 13:54     ` Jesse Pollard
2003-11-24 23:50 ` bill davidsen
2003-11-25  0:22   ` Mike Fedyk
2003-11-25  0:35   ` Chris Wright
2003-11-25  8:15     ` Amon Ott
2003-11-25 16:11     ` Bill Davidsen
2003-11-25 11:26 ` Gianni Tedesco
     [not found] <fa.hevpbbs.u5q2r6@ifi.uio.no>
     [not found] ` <fa.l1quqni.v405hu@ifi.uio.no>
2003-11-24 20:54   ` Andy Lutomirski
2003-11-24 21:16     ` Linus Torvalds
2003-11-24 23:28       ` Ricky Beam
2003-11-24 22:04     ` John Bradford
2003-11-24 22:12       ` Måns Rullgård
2003-11-25 12:10         ` John Bradford
2003-11-25 12:18           ` Måns Rullgård
2003-11-25 13:12             ` John Bradford

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=200311251627.04335.jlell@JakobLell.de \
    --to=jlell@jakoblell.de \
    --cc=jack@suse.cz \
    --cc=jamie@shareable.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=root@chaos.analogic.com \
    /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

all inboxes | Powered by JetHome®