LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Serge E. Hallyn" <serue@us.ibm.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: serue@us.ibm.com, akpm@linux-foundation.org, hch@infradead.org,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [patch 07/10] unprivileged mounts: add sysctl tunable for "safe" property
Date: Thu, 7 Feb 2008 08:05:21 -0600 [thread overview]
Message-ID: <20080207140521.GC4058@sergelap.austin.ibm.com> (raw)
In-Reply-To: <E1JN1p3-0001zF-4l@pomaz-ex.szeredi.hu>
Quoting Miklos Szeredi (miklos@szeredi.hu):
> > > Maybe sysctls just need to check capabilities, instead of uids. I
> > > think that would make a lot of sense anyway.
> >
> > Would it be as simple as tagging the inodes with capability sets? One
> > set for writing, or one each for reading and writing?
>
> Yes, or something even simpler, like mapping the owner permission bits
> to CAP_SYS_ADMIN. There seem to be very few different permissions
> under /proc/sys:
>
> --w-------
> -r--r--r--
> -rw-------
> -rw-r--r--
>
> As long as the group and other bits are always the same, and we accept
> that the owner bits really mean CAP_SYS_ADMIN and not something else,
But I would assume some things under /proc/sys/net/ipv4 or
/proc/sys/net/ath0 require CAP_NET_ADMIN rather than CAP_SYS_ADMIN?
> then the permission check would not need to look at uids or gids at
> all.
>
> Miklos
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2008-02-07 14:05 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-05 21:36 [patch 00/10] mount ownership and unprivileged mount syscall (v8) Miklos Szeredi
2008-02-05 21:36 ` [patch 01/10] unprivileged mounts: add user mounts to the kernel Miklos Szeredi
2008-02-05 21:36 ` [patch 02/10] unprivileged mounts: allow unprivileged umount Miklos Szeredi
2008-02-05 21:36 ` [patch 03/10] unprivileged mounts: propagate error values from clone_mnt Miklos Szeredi
2008-02-05 21:36 ` [patch 04/10] unprivileged mounts: account user mounts Miklos Szeredi
2008-02-05 21:36 ` [patch 05/10] unprivileged mounts: allow unprivileged bind mounts Miklos Szeredi
2008-02-05 21:36 ` [patch 06/10] unprivileged mounts: allow unprivileged mounts Miklos Szeredi
2008-02-05 21:36 ` [patch 07/10] unprivileged mounts: add sysctl tunable for "safe" property Miklos Szeredi
2008-02-06 20:21 ` Serge E. Hallyn
2008-02-06 21:11 ` Miklos Szeredi
2008-02-06 22:45 ` Serge E. Hallyn
2008-02-07 8:09 ` Miklos Szeredi
2008-02-07 14:05 ` Serge E. Hallyn [this message]
2008-02-07 14:36 ` Miklos Szeredi
2008-02-07 16:57 ` Serge E. Hallyn
2008-02-07 15:33 ` Aneesh Kumar K.V
2008-02-07 16:24 ` Miklos Szeredi
2008-02-05 21:36 ` [patch 08/10] unprivileged mounts: make fuse safe Miklos Szeredi
2008-02-05 21:36 ` [patch 09/10] unprivileged mounts: propagation: inherit owner from parent Miklos Szeredi
2008-02-05 21:36 ` [patch 10/10] unprivileged mounts: add "no submounts" flag Miklos Szeredi
2008-02-15 6:21 ` [patch 00/10] mount ownership and unprivileged mount syscall (v8) Andrew Morton
2008-02-15 9:01 ` Christoph Hellwig
2008-02-15 9:09 ` Andrew Morton
2008-02-15 9:14 ` Christoph Hellwig
2008-02-18 11:47 ` Miklos Szeredi
2008-02-23 16:09 ` Al Viro
2008-02-23 17:33 ` Miklos Szeredi
2008-02-23 18:57 ` Al Viro
2008-02-23 19:48 ` Miklos Szeredi
-- strict thread matches above, loose matches on Subject: below --
2008-01-16 12:31 [patch 00/10] mount ownership and unprivileged mount syscall (v7) Miklos Szeredi
2008-01-16 12:31 ` [patch 07/10] unprivileged mounts: add sysctl tunable for "safe" property Miklos Szeredi
2008-01-21 20:32 ` Serge E. Hallyn
2008-01-21 21:37 ` Miklos Szeredi
2008-01-22 20:48 ` Serge E. Hallyn
2008-01-22 22:59 ` Miklos Szeredi
2008-01-23 0:00 ` Serge E. Hallyn
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=20080207140521.GC4058@sergelap.austin.ibm.com \
--to=serue@us.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--subject='Re: [patch 07/10] unprivileged mounts: add sysctl tunable for "safe" property' \
/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
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).