From: Christoph Hellwig <hch@infradead.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
ericvh@gmail.com, smfrench@austin.rr.com, hch@infradead.org
Subject: Re: [RCF] [PATCH] unprivileged mount/umount
Date: Wed, 11 May 2005 09:48:18 +0100 [thread overview]
Message-ID: <20050511084818.GA24495@infradead.org> (raw)
In-Reply-To: <E1DSyQx-0002ku-00@dorka.pomaz.szeredi.hu>
On Tue, May 03, 2005 at 04:31:35PM +0200, Miklos Szeredi wrote:
> This (lightly tested) patch against 2.6.12-rc* adds some
> infrastructure and basic functionality for unprivileged mount/umount
> system calls.
Thanks for doing this.
> Details:
>
> - new mnt_owner field in struct vfsmount
> - if mnt_owner is NULL, it's a privileged mount
> - global limit on unprivileged mounts in /proc/sys/fs/mount-max
I think the name should be different. user-mount-max?
Acutally the accounting in your patch is a little odd, we account for
all mounts, and after mount-max is reached user mounts are denied.
Shouldn't we account only for user mounts?
> - per user limit of mounts in rlimit
> - allow umount for the owner (except force flag)
> - allow unprivileged bind mount to files/directories writable by owner
> - add nosuid,nodev flags to unprivileged mounts
>
> Next step would be to add some policy for new mounts. I'm thinking of
> either something static: e.g. FS_SAFE flag for "safe" filesystems, or
> a more configurable approach through sysfs or something.
>
> Comments?
> --- a6d962c4f559f3644678574a66310084fd13d130/fs/namespace.c (mode:100644 sha1:3b93e5d750ebf8452ea1264251c5b55cc89f48f8)
> +++ uncommitted/fs/namespace.c (mode:100644)
> @@ -42,7 +42,7 @@
> static struct list_head *mount_hashtable;
> static int hash_mask, hash_bits;
> static kmem_cache_t *mnt_cache;
> -
> +struct mounts_stat_struct mounts_stat;
> static inline unsigned long hash(struct vfsmount *mnt, struct dentry *dentry)
minor nipick - please keep a empty line before the function here.
Also I wonder whether we should have struct mounts_stat_struct at all,
just having two variables seems a lot saner to me.
> - if (!capable(CAP_SYS_ADMIN))
> + if (!capable(CAP_SYS_ADMIN) && (nd.mnt->mnt_owner != current->user ||
> + (flags & MNT_FORCE)))
> goto dput_and_out;
although it won't have different results I'd reorder this to make reading
more easy:
if ((nd.mnt->mnt_owner != current->user || (flags & MNT_FORCE)) &&
!capable(CAP_SYS_ADMIN))
> -static int mount_is_safe(struct nameidata *nd)
> +static struct user_struct *mount_is_safe(struct nameidata *nd)
> {
> if (capable(CAP_SYS_ADMIN))
> - return 0;
> - return -EPERM;
> -#ifdef notyet
> - if (S_ISLNK(nd->dentry->d_inode->i_mode))
> - return -EPERM;
> + return NULL;
> +
> + if (!S_ISDIR(nd->dentry->d_inode->i_mode) &&
> + !S_ISREG(nd->dentry->d_inode->i_mode))
> + return ERR_PTR(-EPERM);
> if (nd->dentry->d_inode->i_mode & S_ISVTX) {
> - if (current->uid != nd->dentry->d_inode->i_uid)
> - return -EPERM;
> + if (current->fsuid != nd->dentry->d_inode->i_uid)
> + return ERR_PTR(-EPERM);
> }
> if (permission(nd->dentry->d_inode, MAY_WRITE, nd))
> - return -EPERM;
> - return 0;
> -#endif
> + return ERR_PTR(-EPERM);
> + return current->user;
Currently we do allow bind mounts over every type of file for the super
user. I think we should keep allowing that. Also I think this function
wants a really big comment explaining all the rules for user mounts.
next prev parent reply other threads:[~2005-05-11 8:48 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-03 14:31 [RCF] [PATCH] unprivileged mount/umount Miklos Szeredi
2005-05-04 13:08 ` Eric Van Hensbergen
2005-05-04 14:21 ` Miklos Szeredi
2005-05-04 14:51 ` Eric Van Hensbergen
2005-05-04 15:21 ` Miklos Szeredi
2005-05-11 8:51 ` Christoph Hellwig
2005-05-11 10:31 ` Miklos Szeredi
2005-05-12 21:08 ` Bryan Henderson
2005-05-13 5:47 ` Miklos Szeredi
2005-05-13 7:19 ` Jan Hudec
2005-05-13 8:33 ` Miklos Szeredi
2005-05-13 23:09 ` Bryan Henderson
2005-05-14 6:58 ` Miklos Szeredi
2005-05-16 18:35 ` Bryan Henderson
2005-05-14 11:49 ` Jamie Lokier
2005-05-04 13:47 ` Martin Waitz
2005-05-04 14:34 ` Miklos Szeredi
2005-05-11 8:53 ` Christoph Hellwig
2005-05-11 8:48 ` Christoph Hellwig [this message]
2005-05-11 10:20 ` Miklos Szeredi
2005-05-16 9:34 ` Christoph Hellwig
[not found] <406SQ-5P9-5@gated-at.bofh.it>
[not found] ` <40rNB-6p8-3@gated-at.bofh.it>
[not found] ` <40t37-7ol-5@gated-at.bofh.it>
[not found] ` <42VeB-8hG-3@gated-at.bofh.it>
[not found] ` <42WNo-1eJ-17@gated-at.bofh.it>
2005-05-11 16:41 ` Bodo Eggert <harvested.in.lkml@posting.7eggert.dyndns.org>
2005-05-11 17:07 ` Jamie Lokier
2005-05-11 18:49 ` Miklos Szeredi
2005-05-11 19:05 ` serue
2005-05-11 19:46 ` Bodo Eggert
2005-05-11 20:40 ` Miklos Szeredi
2005-05-11 21:11 ` Jamie Lokier
2005-05-12 3:05 ` serue
2005-05-11 19:35 ` Ram
2005-05-11 20:31 ` Miklos Szeredi
2005-05-11 21:28 ` Jamie Lokier
2005-05-11 22:42 ` Ram
2005-05-11 22:58 ` Eric Van Hensbergen
2005-05-12 1:02 ` Jamie Lokier
2005-05-12 2:18 ` Eric Van Hensbergen
2005-05-12 6:45 ` Jamie Lokier
2005-05-12 13:23 ` Eric Van Hensbergen
2005-05-12 13:47 ` serue
2005-05-12 15:16 ` Jamie Lokier
2005-05-12 12:51 ` serue
2005-05-12 18:51 ` Miklos Szeredi
2005-05-12 19:56 ` Jamie Lokier
2005-05-13 8:55 ` Miklos Szeredi
2005-05-13 1:10 ` Ram
2005-05-13 6:06 ` Miklos Szeredi
2005-05-13 7:25 ` Ram
2005-05-13 8:59 ` Ram
2005-05-13 9:10 ` Miklos Szeredi
2005-05-13 16:53 ` Ram
2005-05-13 17:14 ` Miklos Szeredi
2005-05-13 18:44 ` Alan Cox
2005-05-13 20:56 ` Bryan Henderson
2005-05-12 0:59 ` Jamie Lokier
2005-05-13 6:41 ` Ram
2005-05-11 21:09 ` Jamie Lokier
2005-05-11 21:20 ` Miklos Szeredi
2005-05-11 21:32 ` Jamie Lokier
2005-05-11 19:32 ` Bodo Eggert
2005-05-11 21:23 ` Jamie Lokier
2005-05-11 21:34 ` Miklos Szeredi
2005-05-11 21:36 ` Jamie Lokier
2005-05-12 3:08 ` serue
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=20050511084818.GA24495@infradead.org \
--to=hch@infradead.org \
--cc=ericvh@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=smfrench@austin.rr.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;
as well as URLs for NNTP newsgroup(s).