From: ebiederm@xmission.com (Eric W. Biederman)
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: akpm@linux-foundation.org, serue@us.ibm.com,
viro@ftp.linux.org.uk, linuxram@us.ibm.com,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
containers@lists.osdl.org
Subject: Re: [patch 3/8] account user mounts
Date: Sun, 22 Apr 2007 01:49:22 -0600 [thread overview]
Message-ID: <m1lkgk26il.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <E1HfWDh-00046V-00@dorka.pomaz.szeredi.hu> (Miklos Szeredi's message of "Sun, 22 Apr 2007 09:10:49 +0200")
Miklos Szeredi <miklos@szeredi.hu> writes:
>> > From: Miklos Szeredi <mszeredi@suse.cz>
>> >
>> > Add sysctl variables for accounting and limiting the number of user
>> > mounts.
>> >
>> > The maximum number of user mounts is set to 1024 by default. This
>> > won't in itself enable user mounts, setting a mount to be owned by a
>> > user is first needed
>>
>> Since each mount has a user can we just make this a per user rlimit?
>>
>> If we are going to implement a sysctl at this point I think it should
>> be a global limit that doesn't care if who you are. Even root can
>> have recursive mounts that attempt to get out of control.
>
> Recursive bind mounts are done carefully enough, so they don't get out
> of control.
>
> Recursive mount propagations can get out of control. But root can
> shoot itself in the foot any number of ways, and it's not for the
> kernel to police that.
Yes. It is.
This is mostly about removing special cases.
We routinely have limits on resources that are global and apply
to root along with every one else. Root can change them but
they still apply to root. Things like the number of inodes
in the system or the total number of files.
Since it is perfectly possible to do a per user rlimit at this stage
in the design. I contend that either:
- We implement a per user rlimit of mounts.
- We implement a global limit on mounts.
No other case makes sense. The previous objections were at least in
part because the limit only applied to user mounts but the name of
the limit did not apply to user mounts.
>> Also currently you are not checking the max_users. It looks like
>> you do this in a later patch but still it is a little strange to
>> allow user own mounts and have accounting but to not check the
>> limit at this state.
>
> Yeah, but at this stage user mounts are not yet allowed, so this is
> safe.
Eric
next prev parent reply other threads:[~2007-04-22 7:51 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-20 10:25 [patch 0/8] mount ownership and unprivileged mount syscall (v4) Miklos Szeredi
2007-04-20 10:25 ` [patch 1/8] add user mounts to the kernel Miklos Szeredi
2007-04-21 7:55 ` Andrew Morton
2007-04-21 8:06 ` Miklos Szeredi
2007-04-21 13:14 ` Eric W. Biederman
2007-04-22 7:02 ` Miklos Szeredi
2007-04-22 7:43 ` Eric W. Biederman
2007-04-22 8:05 ` Miklos Szeredi
2007-04-22 16:22 ` Miklos Szeredi
2007-04-20 10:25 ` [patch 2/8] allow unprivileged umount Miklos Szeredi
2007-04-21 7:55 ` Andrew Morton
2007-04-21 8:01 ` H. Peter Anvin
2007-04-21 8:09 ` Miklos Szeredi
2007-04-21 8:36 ` Andrew Morton
2007-04-21 12:53 ` Eric W. Biederman
2007-04-22 6:47 ` Miklos Szeredi
2007-04-22 7:09 ` Eric W. Biederman
2007-04-22 7:32 ` Miklos Szeredi
2007-04-21 13:29 ` Eric W. Biederman
2007-04-22 7:05 ` Miklos Szeredi
2007-04-20 10:25 ` [patch 3/8] account user mounts Miklos Szeredi
2007-04-21 7:55 ` Andrew Morton
2007-04-21 13:37 ` Eric W. Biederman
2007-04-22 7:10 ` Miklos Szeredi
2007-04-22 7:49 ` Eric W. Biederman [this message]
2007-04-22 8:08 ` Miklos Szeredi
2007-04-20 10:25 ` [patch 4/8] propagate error values from clone_mnt Miklos Szeredi
2007-04-21 13:40 ` Eric W. Biederman
2007-04-20 10:25 ` [patch 5/8] allow unprivileged bind mounts Miklos Szeredi
2007-04-21 14:00 ` Eric W. Biederman
2007-04-22 7:19 ` Miklos Szeredi
2007-04-20 10:25 ` [patch 6/8] put declaration of put_filesystem() in fs.h Miklos Szeredi
2007-04-20 10:25 ` [patch 7/8] allow unprivileged mounts Miklos Szeredi
2007-04-21 7:55 ` Andrew Morton
2007-04-21 8:13 ` Miklos Szeredi
2007-04-21 8:23 ` Miklos Szeredi
2007-04-21 14:10 ` Eric W. Biederman
2007-04-21 15:43 ` Jan Engelhardt
2007-04-21 16:57 ` Eric W. Biederman
2007-04-21 17:10 ` Jan Engelhardt
2007-04-21 21:00 ` Eric W. Biederman
2007-04-22 8:19 ` Miklos Szeredi
2007-04-21 22:06 ` Andi Kleen
2007-04-21 21:33 ` Eric W. Biederman
2007-04-22 0:46 ` Shaya Potter
2007-04-20 10:25 ` [patch 8/8] allow unprivileged fuse mounts Miklos Szeredi
2007-04-21 7:55 ` Andrew Morton
2007-04-21 8:16 ` Miklos Szeredi
2007-04-21 14:18 ` Eric W. Biederman
2007-04-22 7:22 ` Miklos Szeredi
2007-04-20 12:42 ` [patch 0/8] mount ownership and unprivileged mount syscall (v4) Serge E. Hallyn
2007-04-20 16:33 ` Eric W. Biederman
2007-04-25 0:04 ` Karel Zak
2007-04-25 1:04 ` Eric W. Biederman
2007-04-25 7:18 ` Miklos Szeredi
2007-04-25 9:23 ` Karel Zak
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=m1lkgk26il.fsf@ebiederm.dsl.xmission.com \
--to=ebiederm@xmission.com \
--cc=akpm@linux-foundation.org \
--cc=containers@lists.osdl.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxram@us.ibm.com \
--cc=miklos@szeredi.hu \
--cc=serue@us.ibm.com \
--cc=viro@ftp.linux.org.uk \
/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®