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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120511034945.GA15892@mobil.systemanalysen.net>
Date:	Fri, 11 May 2012 05:49:45 +0200
From:	Roland Eggner <edvx1@...temanalysen.net>
To:	Ludwig Nussel <ludwig.nussel@...e.de>
Cc:	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	Jan Kara <jack@...e.cz>, Rob Landley <rob@...dley.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andreas Dilger <adilger.kernel@...ger.ca>,
	"Theodore Ts'o" <tytso@....edu>,
	"open list:EXT2 FILE SYSTEM" <linux-ext4@...r.kernel.org>,
	"open list:DOCUMENTATION" <linux-doc@...r.kernel.org>
Subject: Re: [PATCH RESEND] implement uid and gid mount options for ext2,
 ext3 and ext4

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@...dley.net>
> Signed-off-by: Ludwig Nussel <ludwig.nussel@...e.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

Content of type "application/pgp-signature" skipped