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@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.
>
>
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
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
