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

[Roland Eggner <edvx1@systemanalysen.net>]

[-- Attachment #1: Type: text/plain, Size: 4062 bytes --]

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.



Thanks,
Roland Eggner

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]