lkml.org 
[lkml]   [2009]   [Jul]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 1/2] implement uid mount option for ext2
    On Jul 25, 2009  17:44 +0200, Ludwig Nussel wrote:
    > Andreas Dilger wrote:
    > > To be honest, rather than mapping the specified file to uid == 0/gid == 0
    > > it would be more useful (and safe) to allow specifying a mapping from one
    > > UID to another, or have the on-disk UID always be set to/from the specified
    > > UID. Given that your original problem is for the user having UIDX on
    > > system X and UIDY on system Y, you should just specify the X->Y mapping
    > > explicitly, instead of an implicit X->0 mapping. Otherwise, if the user
    > > is unable to access root-owned files on either one of system X or Y your
    > > current patch fails.
    >
    > That's unnecessarily complicated. You don't have to keep track of
    > your user ids when using e.g. FAT formatted USB memory sticks
    > either. The files just always magically appear to be owned by the
    > user who mounted the file system. The goal is to have it just as
    > simple with ext2 on the USB stick.

    But that isn't how this patch works either. It only makes files owned
    by root available to the mounting user, and then (to add confusion)
    files created by the user end up being owned by root. That means it
    won't be a generally useful feature until every system also has this
    patch. Also, by using root for the file owner you potentially expose
    the system to more security risks compared to using any other user.

    > If one of the systems doesn't mount media with the uid option the
    > files might be unaccesible, that's true.

    ... but that is the whole point of this patch - to make files on the
    device accessible between multiple systems, so if it doesn't do that
    right out of the box it isn't a very useful feature.

    > IOW on that system the situation is no different from
    > today any you'll have to resort to the same workarounds you have to
    > use today already (like sudo chown -R $USER or chmod 777).

    But it also makes the problem worse, because the new files are owned
    by root instead of either the UID on the original system or the UID
    on the current system.


    A more "obvious" solution would be to just have the filesystem mounted
    with this option to make ALL files appear to be owned by the UID specified
    to the "uid=${localuid}", which would at least more closely match the
    behaviour of the fat/vfat filesystems with the uid= option. New files
    could be created using the local UID with no more effort than creating
    them with uid=0, but there would be less surprise on another system if
    files don't magically appear as owned by root.

    My further suggestion was that if it is possible to optionally specify
    the remote UID then at least one side does not have to have this patch
    in order to mount and use the filesystem. Hence, my suggestion to have
    "uid={localuid}[={diskuid}]". The [={diskuid}] part could be optional,
    and doesn't add any significant complication to the patch, AFAICS.
    Initialize the diskuid = localuid, and if the additional diskuid is given
    use that instead, for all inodes written to the disk.


    Cheers, Andreas
    --
    Andreas Dilger
    Sr. Staff Engineer, Lustre Group
    Sun Microsystems of Canada, Inc.



    \
     
     \ /
      Last update: 2009-07-27 21:17    [W:0.024 / U:29.808 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site