All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ted Ts'o <tytso@mit.edu>
To: Rob Landley <rob@landley.net>
Cc: Ludwig Nussel <ludwig.nussel@suse.de>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	Jan Kara <jack@suse.cz>,
	Andrew Morton <akpm@linux-foundation.org>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	"open list:EXT2 FILE SYSTEM" <linux-ext4@vger.kernel.org>,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>
Subject: Re: [PATCH RESEND] implement uid and gid mount options for ext2, ext3 and ext4
Date: Fri, 11 May 2012 12:46:05 -0400	[thread overview]
Message-ID: <20120511164605.GC6467@thunk.org> (raw)
In-Reply-To: <4FAD2161.3090108@landley.net>

On Fri, May 11, 2012 at 09:25:37AM -0500, Rob Landley wrote:
> Well it's certainly a point of view. Luckily, FAT already _has_ the
> workaround we're discussing.  The objections were mainly "can't the VFS
> do this for us?" and the answer, upon closer inspection, turned out to
> be "not easily, no, the VFS takes option flags instead of parsing string
> options so doesn't have some necessary infrastructure".

The only reasonable use case I can imagine for this feature is one
where someone wants to use a removable storage device (which could be
a USB thumb drive to a USB HDD to a SSD in a USB 3.0 enclosure) as an
interchange device between Unix systems which do not have compatible
uid/gid spaces.

So perhaps the right approach is that we should have an ext2/3/4
read-only feature flag which enforces a default of nosuid and all
files to be read-only and world-readable.  There would be mount
options which could modify this default behaviour so that the files
could be writeable by a particular uid or gid, and another mount
option which would change the permission bits seen for that file
system from 0755/0644 for directories/files to 0700/0600.

Basically, the idea is we should mark the file system in an explicit
way that it is intended for interchange across incompatible uid/gid
spaces, with defaults which minimize security risk.  The fact that all
files become world-readable is potentially a risk, but if the user is
willing to put their private files on a removeable media that could
easily be dropped in a parking lot, or otherwise stolen or lost,
that's a potential risk that they've implicitly accepted in any case;
we might as well make it be explicit.

							- Ted


  parent reply	other threads:[~2012-05-11 16:46 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-10 14:42 [PATCH RESEND] implement uid and gid mount options for ext2, ext3 and ext4 Ludwig Nussel
2012-05-10 15:00 ` Jan Kara
2012-05-10 15:30   ` Ted Ts'o
2012-05-11  3:49 ` Roland Eggner
2012-05-11 15:31   ` Boaz Harrosh
2012-05-14 23:15     ` NeilBrown
2012-05-16  7:25       ` Boaz Harrosh
     [not found]   ` <4FAD2161.3090108@landley.net>
2012-05-11 16:46     ` Ted Ts'o [this message]
2012-05-11 17:18       ` Boaz Harrosh
     [not found]         ` <20120511192235.GE6467@thunk.org>
2012-05-13 11:46           ` Boaz Harrosh
     [not found]       ` <4FADB860.2000009@landley.net>
2012-05-13  4:24         ` Ted Ts'o

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=20120511164605.GC6467@thunk.org \
    --to=tytso@mit.edu \
    --cc=adilger.kernel@dilger.ca \
    --cc=akpm@linux-foundation.org \
    --cc=jack@suse.cz \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ludwig.nussel@suse.de \
    --cc=rob@landley.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.