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,
	viro@ftp.linux.org.uk, kzak@redhat.com,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	containers@lists.osdl.org, util-linux-ng@vger.kernel.org
Subject: Re: [patch 07/10] unprivileged mounts: add sysctl tunable for "safe" property
Date: Tue, 22 Jan 2008 18:00:40 -0600	[thread overview]
Message-ID: <20080123000040.GA6931@sergelap.austin.ibm.com> (raw)
In-Reply-To: <E1JHS5h-0001EC-QD@pomaz-ex.szeredi.hu>

Quoting Miklos Szeredi (miklos@szeredi.hu):
> > > > What do you think about doing this only if FS_SAFE is also set,
> > > > so for instance at first only FUSE would allow itself to be
> > > > made user-mountable?
> > > > 
> > > > A safe thing to do, or overly intrusive?
> > > 
> > > It goes somewhat against the "no policy in kernel" policy ;).  I think
> > > the warning in the documentation should be enough to make sysadmins
> > > think twice before doing anything foolish:
> > 
> > Warning in which documentation?  A sysadmin considering setting fs_safe
> > for ext2 or xfs isn't going to be looking at fuse docs, which I think is
> > what you're talking about.  Are you going to add a file under
> > Documentation/filesystems?
> 
> Yes, I meant documentation of the new sysctl tunable in
> Documentation/filesystems/proc.txt:

Argh, sorry.

> > Index: linux/Documentation/filesystems/proc.txt
> > ===================================================================
> > --- linux.orig/Documentation/filesystems/proc.txt	2008-01-16 13:25:07.000000000 +0100
> > +++ linux/Documentation/filesystems/proc.txt	2008-01-16 13:25:09.000000000 +0100
> > @@ -43,6 +43,7 @@ Table of Contents
> >    2.13	/proc/<pid>/oom_score - Display current oom-killer score
> >    2.14	/proc/<pid>/io - Display the IO accounting fields
> >    2.15	/proc/<pid>/coredump_filter - Core dump filtering settings
> > +  2.16	/proc/sys/fs/types - File system type specific parameters
> >  
> >  ------------------------------------------------------------------------------
> >  Preface
> > @@ -2283,4 +2284,21 @@ For example:
> >    $ echo 0x7 > /proc/self/coredump_filter
> >    $ ./some_program
> >  
> > +2.16 /proc/sys/fs/types/ - File system type specific parameters
> > +----------------------------------------------------------------
> > +
> > +There's a separate directory /proc/sys/fs/types/<type>/ for each
> > +filesystem type, containing the following files:
> > +
> > +usermount_safe
> > +--------------
> > +
> > +Setting this to non-zero will allow filesystems of this type to be
> > +mounted by unprivileged users (note, that there are other
> > +prerequisites as well).
> > +
> > +Care should be taken when enabling this, since most
> > +filesystems haven't been designed with unprivileged mounting
> > +in mind.
> > +
> >  ------------------------------------------------------------------------------
> > 
> 
> Do you think this is enough?  Or do we need something more, to prevent
> sysadmin inadvertently setting this for an unsafe filesystem?

I would think something more would be good.  First explaining
that fuse should be safe modulo warnings in the fuse documentation,
procfs and sysfs may be safe, while other filesystems are not known safe
at all.

Then explaining the dangers with not-known-safe filesystems and what is
needed to make them safe.  Clearly making sure input validation is
properly done so for instance getsb() doesn't turn into a buffer
overflow, etc.

Such a checklist also would be useful for holding a meaningful discussion
about the other filesystems and maybe turning some people loose on
an audit of other filesystems.

thanks,
-serge

  reply	other threads:[~2008-01-23  0:01 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-16 12:31 [patch 00/10] mount ownership and unprivileged mount syscall (v7) Miklos Szeredi
2008-01-16 12:31 ` [patch 01/10] unprivileged mounts: add user mounts to the kernel Miklos Szeredi
2008-01-16 12:31 ` [patch 02/10] unprivileged mounts: allow unprivileged umount Miklos Szeredi
2008-01-16 12:31 ` [patch 03/10] unprivileged mounts: propagate error values from clone_mnt Miklos Szeredi
2008-01-16 12:31 ` [patch 04/10] unprivileged mounts: account user mounts Miklos Szeredi
2008-01-16 12:31 ` [patch 05/10] unprivileged mounts: allow unprivileged bind mounts Miklos Szeredi
2008-01-16 12:31 ` [patch 06/10] unprivileged mounts: allow unprivileged mounts 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 [this message]
2008-01-16 12:31 ` [patch 08/10] unprivileged mounts: make fuse safe Miklos Szeredi
2008-01-21 20:41   ` Serge E. Hallyn
2008-01-16 12:31 ` [patch 09/10] unprivileged mounts: propagation: inherit owner from parent Miklos Szeredi
2008-01-21 20:23   ` Serge E. Hallyn
2008-01-16 12:31 ` [patch 10/10] unprivileged mounts: add "no submounts" flag Miklos Szeredi
2008-02-05 21:36 [patch 00/10] mount ownership and unprivileged mount syscall (v8) 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
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

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=20080123000040.GA6931@sergelap.austin.ibm.com \
    --to=serue@us.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=containers@lists.osdl.org \
    --cc=hch@infradead.org \
    --cc=kzak@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=util-linux-ng@vger.kernel.org \
    --cc=viro@ftp.linux.org.uk \
    --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).