Permissions for UDF filesystem on removable devices

[pali]

Hi! Please consider adding additional mount options uid=ignore and gid=ignore for UDF filesystems when mounting removable devices. Mount options -o uid=<UID>,uid=ignore cause that all files visible in VFS would be owned by <UID> (uid=<UID>) and newly created files on UDF filesystem would be stored without UID (uid=ignore). UDF filesystem itself supports storing files/directories without UID/GID which I think is suitable for removable devices where numerical owner and group does not make sense.

For all details, see updated mount(8) manpage: http://man7.org/linux/man-pages/man8/mount.8.html

[vpodzime]

IIRC, this is being done for some other file systems too, but these don't support POSIX ownership at all, I think. What happens if files have ownership and the suggested mount options are used?

[pali]

When you specify uid=<UID> mount option then UDF driver propagates to VFS uid <UID> for all files and directories despite the fact if files stored on UDF filesystem have uids stored or not.

[pali]

Basically if you already have removable disk on which everything is owned by user 1005:1005 and you connect it to the different system on which is currently logged user 1004:1004, then you are unable to do anything with these files. For removable disk devices does not make much sense to use or store uid/gid information, nor to enforce it.

[vpodzime]

For removable disk devices does not make much sense to use or store uid/gid information, nor to enforce it.

I don't think this is necessary the case. I mean, it is, for desktop users, but I can imagine a corporation with identity management setup that makes sure UIDs are unified/synchronized over their whole infrastructure and things like Bluray or DVD discs being used for some data storage/sharing.

Is there a way to easily distinguish between a UDF FS that is using POSIX ownership and a one that has always been using uid=ignore?

[pali]

Is there a way to easily distinguish between a UDF FS that is using POSIX ownership and a one that has always been using uid=ignore?

No (at least not easily and you do not want to do it).

Every file and directory in UDF has stored UID and GID. Just there is one UID and one GID value which means "no value stored".

So you could implement your own userspace UDF filesystem reader. Scan whole filesystem, every file and check its UID and GID entries. And check if all UID/GID values for all files are that one which means "no value stored".

[vpodzime]

That's what I kind of expected.

[tbzatek]

The upcoming changes will allow to specify extra options like uid=ignore and I've actually used this case as an example. This needs to be overriden by sysadmin first however, for security reasons.

UDisks doesn't support mount options differentiation by removable/non-removable classification by default and I'm not convinced we'd want to go that way. Removable media detection is not always reliable and is prone to spoofing - think a HDD being connected via SATA, eSATA, FireWire, Thunderbolt or USB enclosure at one moment and a different way just a moment later.

It is also possible to place extra udev rules now and override mount options if sysadmin wishes. This is tailored for corporate or similarly controlled environment.

[pali]

Could not you classify removable media for this ticket as medias which do not have entry in fstab?

This needs to be overriden by sysadmin first however, for security reasons.

What is the security issue there? Behavior of uid=<uid>,uid=ignore is already used for FAT32 filesystems. So why cannot be it used also for UDF?

[tbzatek]

Could not you classify removable media for this ticket as medias which do not have entry in fstab?

Mount options from fstab are respected in case a record exists. Mount option defaults apply only in case of dynamic mounts.

This needs to be overriden by sysadmin first however, for security reasons.

What is the security issue there? Behavior of uid=<uid>,uid=ignore is already used for FAT32 filesystems. So why cannot be it used also for UDF?

The difference is that FAT32 filesystem doesn't store ownership natively and we're providing fake information. However for UDF and other ownership-aware filesystems users may actually want to store proper ownership (and file modes if applicable).

[pali]

The difference is that FAT32 filesystem doesn't store ownership natively and we're providing fake information. However for UDF and other ownership-aware filesystems users may actually want to store proper ownership (and file modes if applicable).

It depends... If user is using particular flash disk for sharing data between more machines, then storing and interpreting user / group id information is harmfull. On each machine could be (and on multiuser systems are) different ids and so it leads to situation that file written on one machine cannot be read on another machine. And when FAT32 is used, there is no such problem (because of using fake ids). I saw that this situation happened lot of times and this is reason why FAT is prefered and filesystems with POSIX permissions are marked by more users as BAD and unsuitable for data storage.

Plus, it really does not make sense to interpret POSIX permissions for files stored by Windows UDF driver.

[pali]

I still do not see reason when user want could want to preserve user and group id for usb flash disk which is going to connect to his laptop and do "user mount" of it.

Security aspect does not make sense as this user can put on own flash disk what wants (via other computer), including setuid root binaries... Storage if fully in his own control.

So I do not see reason why Linux should disallow accessing some files on his own flash disk, just because his user id (on computer which is going to be used for accessing that flash disk) does not match user id stored for particular file on disk. Windows does not do such checks and allow user to access files on UDF filesystem (even files have stored POSIX user id).

For removable flash disks with UDF this just make problems, I do not see any benefit from it.

If you want to preserve user id and group id, it means you want to use multi user environment and in this case you should have sysadmin rights for such thing to do, so do admin mount.

(All this is for user mounts, without involving root/sudo/sysadmin mount)

[tbzatek]

I guess we'll need to write down particular use cases and decide which way to go.