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@xxxxxxxxxxx>
> Signed-off-by: Ludwig Nussel <ludwig.nussel@xxxxxxx>
> ---
> 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:
pgpNgzh2N7Rkq.pgp
Description: PGP signature
