linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Boaz Harrosh <bharrosh@panasas.com>
To: "Ted Ts'o" <tytso@mit.edu>, Rob Landley <rob@landley.net>,
	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 20:18:35 +0300	[thread overview]
Message-ID: <4FAD49EB.5010804@panasas.com> (raw)
In-Reply-To: <20120511164605.GC6467@thunk.org>

On 05/11/2012 07:46 PM, Ted Ts'o wrote:

> 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.


How is that ext* special? You said "Unix systems" there are lots more
FSs more common to "Unix" systems

> 
> 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.


They can make that explicit by formatting as vfat or ntfs, fully
interchangeable not only on "Unix".

Or by doing the proper copy when filling up the media in the
first place.

As a maintainer of ext4 filesystem which is the official system for
Linux in many distrows, still. Please resists any such crap.
User "convenience-vs-security was never a geol of Unix.

> 
> 							- Ted


Please, for your own peace of mind, in an historical perspective,
don't do this

Boaz


  reply	other threads:[~2012-05-11 17:18 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
2012-05-11 17:18       ` Boaz Harrosh [this message]
     [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=4FAD49EB.5010804@panasas.com \
    --to=bharrosh@panasas.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=akpm@linux-foundation.org \
    --cc=jack@suse.cz \
    --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 \
    --cc=tytso@mit.edu \
    /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).