Re: [PATCH RESEND] implement uid and gid mount options for ext2, ext3 and ext4

[Boaz Harrosh <bharrosh@panasas.com>]

On 05/11/2012 06:49 AM, Roland Eggner wrote:

> On 2012-05-10 Thu 16:42 +0200, Ludwig Nussel wrote:
>> …
>> When using 'real' file systems on removable storage devices such as
>> hard disks or usb sticks people quickly face the problem that their
>> Linux users have different uids on different machines. Therefore one
>> cannot modify or even read files created on a different machine
>> without running chown as root or storing everything with mode 777.
>> Simple file systems such as vfat don't have that problem as they
>> don't store file ownership information and one can pass the uid
>> files should belong to as mount option.
>>
>> The following two patches (for 3.4.0-rc4) implement the uid (and
>> gid) mount option for ext2, ext3 and ext4 to make them actually
>> useful on removable media. If a file system is mounted with the uid
>> option all files appear to be owned by the specified uid. Only newly
>> created files actually end up with that uid as owner on disk though.
>> Ownership of existing files cannot be changed permanently if the uid
>> option was specified.
>>
>> Acked-by: Rob Landley <rob@landley.net>
>> Signed-off-by: Ludwig Nussel <ludwig.nussel@suse.de>
>> ---
>>  Documentation/filesystems/ext2.txt |    9 ++++++
>>  Documentation/filesystems/ext3.txt |    9 ++++++
>>  Documentation/filesystems/ext4.txt |    9 ++++++
>>  fs/ext2/ext2.h                     |    8 +++++
>>  fs/ext2/inode.c                    |   42 ++++++++++++++++++++------
>>  fs/ext2/super.c                    |   57 +++++++++++++++++++++++++++++++++++-
>>  fs/ext3/ext3.h                     |    8 +++++
>>  fs/ext3/inode.c                    |   50 ++++++++++++++++++++++---------
>>  fs/ext3/super.c                    |   57 +++++++++++++++++++++++++++++++++++-
>>  fs/ext4/ext4.h                     |    4 ++
>>  fs/ext4/inode.c                    |   50 ++++++++++++++++++++++---------
>>  fs/ext4/super.c                    |   49 ++++++++++++++++++++++++++++++-
>>  12 files changed, 311 insertions(+), 41 deletions(-)
>>
>> …
> 
> 
> In short:
> .........
> Problem solving at its root is more efficient than at “end of pipe”.
> 
> 
> 
> IMHO this is an example of “end of pipe“ thinking with following downsides:
> ...........................................................................
> *  Maintainers point of view:
>    *  Introduces new problems:  Breaking holes in the access restrictions
>       provided by the Linux kernel at will of unprivileged users would render
>       the kernel unusable for reliable operation in multiuser environments.
>    *  Adds code complexity and risk of bugs.
>    *  Adds future maintainance load.
> *  Users point of view:
>    *  Editing /etc/fstab or using mount commands with options not in
>       /etc/fstab require root privileges anyway, at least on sane systems.
>    *  Adds usage complexity (new vs. old files, on disk vs. pretended UIDs …).
>    *  Adds risk of usage errors.
> 
> 
> 
> IMHO the “right thing to do” is to solve the problem at its root:
> .................................................................
> My habit is, whenever I use {group,user}add commands:
> *  In advance I create a list of all current and future users (user, GID, UID)
>    common to all systems that might exchange files.  The list is designed to
>    have “headroom” for future additions.
> *  I always consult this list and use options --gid $userGID --uid $userUID to
>    {group,user}add commands.
> *  Exchanging files with an unforeseen system is an exception, which requires
>    root privileges anyway,
> 
> Advantages:
> *  Decent migration of files to other systems via backups, external storage …
> *  No NEW wholes in the access restrictions provided by the Linux kernel.
> *  No NEW kernel code possibly introducing bugs.
> *  No need to learn new mount options.
> *  No NEW risks of usage errors.
> 
> 
> Summary:
> ........
> *  If UIDs differ on machines FORESEEN for file exchange, this is an
>    administrator error, not a kernel deficit.
> *  File exchange with an UNFORESEEN system requires root privileges anyway.
> 
> 


I agree with Ludwig completely!!! Thanks, good policy rules.

1. ext* are nothing special and are not a special domain of removable media.
   (If any vfat is dominant at that end)

2. What the hell does removable-media means? and how is it different then
   something else? is ext* over iscsi removable? a soft-mount NFS, is it
   removable?

Above sounds to me like a huge security breach, and actually a data-corruption.

In the NFS world I hang around, we constantly encounter multiple domain
uid/gid views, and it does not mean we blow a hole in POSIX security rules.

The root that mounts this FS can just copy+chmod or just-chmod them.
Next we'll see auto-mounters use these flags and goodbye file-access-control.

There is some convenience you do not allow. a password-less root, and no access
control at all is most convenient would you say?

I bet this code opens up an attack vector like crazy. Windows viruses welcome.

No thanks
Boaz

> 

> Thanks,
> Roland Eggner