log of Logfish.net

There is a problem with user permissions and portable disks. UIDs are number and not portable between Linux systems (the same number can be a completely different user) and the same holds for groups. This leads to a problem when you start using a filesystem which support permissions on something like an USB stick but this is where the problems start, because FAT32 seems to be the only solution. Let me break the problem down for you...

If another person only has userspace permissions on a machine (no root access), the only way to grant that other person to write on your protable disk, is one of the following:
1. Know their UID/GID up front, and chmod some place for the write.
2. Reformat to a filesystem without permission storage (FAT16/FAT32).
3. Do a chmod for all files on disk, to allow everybody to write everywhere.
4. Create a TAR archive and place this on a FAT32 filesystem.

All of these options have disadvantages and option 2 is currently the most common solution and this makes 4 the best solution for source trees with symlinks. Probably the simplest way of viewing this problem is by comparing an USB disk to a rewritable CD or a floppy disk: you share the data an all premission to that data, by sharing the medium. Currently, none of the user permission aware filesystems seem to be able to ignore or rewrite UID/GID when doing a userspace mount (which is good for most situations).

As 4 seems to be the best solution, this is what most people will do when encountering this problem. So it is not impossible, but requires more work then should be needed. What makes this problem a real problem, is that most solutions I can think of, are either weird (an agreement and chmod being run) or require changes in filesystem drivers (which seems like a big thing).

Problems with current work-arounds

Know their UID/GID up front, and chmod some place for the write.

The problem with this should be obvious: you would have to know the UID or GID of the user you are going to give the medium to. Most people don't know their own numerical UID or GID and guessing is not an option.

Reformat to a filesystem without permission storage (FAT16/FAT32).

Formatting as FAT32 is the most common solution today: when you are going to do a presentation or walk around gathering data, this will allow all places you may encounter to add data to your portable drive. However, there are things you can't share on that. Trying to copy a symlink to this system is impossible. Any script with execution flags set, won't work. This means that all source will have to be compressed and decompressed using a system that knows about these kinds of files and allows for the storage of the permissions: tar. Not a good solution, but the best at the moment.

Do a chmod for all files on disk, to allow everybody to write everywhere.
This will help allot, but you will have to do this before every umount, because your default umask will protect you from creating this kind of security hole in your home directory. This means you will have to chmod your whole drive before every umount, so this is not an ideal solution.

Possible solutions

These are solutions I can think of, not all are good enough and I think that handling this at the filesystem creation level (setting a flag while formatting, or setting a standard on the label) would probably be the cleanest solution. Most filesystems already support overwritting to a given user/gid when mounting the system, so the only real problem left is how to communicate to pmount (or other userspace mounting) that for the disk that was just inserted should be mounted with these options, while allowing other disks to mount normally. Possible solutions to this (I can think of) are:

Add special character/format to the label of the disk

By adding a special character (like the "." in hidden files) in the label of the filesystem could communicate user-writability to pmount/mount. It would then be possible for pmount/mount to run a chown currentuser.currentuser on the whole tree before passing of root rights. There would have to be an agreement on the kind of character to use and where to use it.
Although it is probably possible to do something with the UUID to get the same result (agree on a special UUID), this may violate the whole uniqueness that a UUID should adhere to.

Add a filesystem flag

Adding a filesystem flag, will allow the creator of the filesystem (any
person with root access) to communicate to the driver (which is
handling the file permissions) to rewrite them to the user who is
mounting the system. Mount would have to communicate this, so this
solution is probably to hard to implement.

Add a special tag/metadata to the root of the new filesystem

Allow for a special kind of tag/metadata which would allow all users to
write as a specified user to all subdirectories and files of that
directory. This would allow the user to create a special kind of
"anywhere access" directory to the normal filesystem. Although this may
sound like chmod a+rwx, it's not because the filesystem driver will
make sure that no files in that directory can be created without that
proporty. It will enforce the chmod a+rw which will keep any userspace
user from creating undeletable/modifiable files in that directory
(after creating and unmounting, other people mounting it will still be
able to delete the newly added files). This is probably the coolest,
but also most complex solution to this problem.

Thanks go out to
The ext4 developers, for not flaming me: http://thread.gmane.org/gmane.comp.file-systems.ext4/3930