Changing /etc/udisks-glue.conf seems to have no effect on the permissions of the mount point of micro-SD, USB, etc., disks.
I tried changing the “chmod” command in “match other-partitions” and it had no effect. Deleting it completely also had no effect…the mount directory is still 777. I then added an “automount_options” line to set the perms, but that resulted in no mount at all. More investigation showed that an exFAT partition won’t automount with any options set, yet a manual mount of the same partition works fine.
I really don’t like having a world-writable “real” directory (as opposed to /tmp) anywhere on the disk, as it means that any attack that succeeds in getting a login (even non-root) will have a place to write a lot of data.
It depends on your filesystem. If you want permissions to be handled properly, then I’m not sure that exFAT is a good choice of filesystem.
exFAT isn’t handle fantastically on Linux, so we have a wrapper.
I’d be happy to welcome a PR to improve the functionality if it can be done in a better way. What we can’t do is force people that attach a USB disk and have to configure permissions in a complex manner without a GUI.
In this case, I’d suggest disabling the automounter and mounting the disk with fstab and locking it down accordingly.
exFAT is transportable, so it’s the best for things like SD cards. It can’t do any permissions at all, except at the mount point, which is why this is a big deal.
The point I was trying to make is that the wrapper does nothing at all. After the mount is completed, permissions on the mount point can’t be changed, which is why I was trying to use the “automount_options” to set the perms at mount time.
This works in fstab (dmask=0002,fmask=0113,uid=1000,gid=1000), but not in /etc/udisks-glue.conf. I would love to be able to send you something that fixes the issue, but I have no clue where the breakdown is, or even where logs of errors in the udisk mounting end up. If I could see that, maybe I could debug the dmask and fmask not doing anything.
Having it work as a udisk and not using fstab means that SD cards with different labels will be mounted in different directories under /media, and that USB sticks with exFAT will be handled the same way, allowing easier use of multiple sticks. So, the idea behind what you are trying to do is great, and I’d just like to see that it actually works.
Note that the mount point (named based on the volume label of the card) has mode 777.
sudo chmod 775 /media/MOUNTPOINT
ls -al /media
Note that the perms haven’t changed.
Next, edit /etc/udisks-glue.conf, the “match other-partitions” section. If this is not enough detail for you to find it, then you likely don’t understand anything I am saying. Change the following line:
sudo chmod a+rwx "%mount_point" 2>/dev/null
to
sudo chmod 775 "%mount_point" 2>/dev/null
Then:
sudo umount /media/MOUNTPOINT
sudo systemctl restart udisks-glue.service
ls -al /media
Note that mount point is still mode 777
Next, edit /etc/udisks-glue.conf, the “match other-partitions” section. Add the following line after the “automount = true” line:
automount_options = { 'fmask=0113','dmask=0002' }
Then:
sudo umount /media/MOUNTPOINT
sudo systemctl restart udisks-glue.service
ls -al /media
Note that mount point isn’t there at all…the mount has failed. This means that the line we just added broke it, when it is supposed to set the mount options.
To verify that those mount options aren’t a problem, add the following line to /etc/fstab:
Note that the mount point has perms of 775 and is owned by osmc, just like we wanted, and just like the udisks-glue service is supposed to allow us to do.
So, exFAT supports mounting with a non-root user as the owner, and perms other than 777, but the udisks-glue service doesn’t seem to be able to do that, despite the fact that there is syntax in the config file that seems to support it.
All I’m asking is: where is the log file that shows what the udisks-glue service is trying to do?
If I knew that, I could maybe figure out a way to make it do what obviously can be done, and that it seems to want to be able to allow me to do.
So, what you’re saying is you have hacked up a helper service with a broken config file that not only does absolutely nothing, but actually breaks mounting when you attempt to use the syntax in the file? Yep, if you add the “automount_options” line to the “match other-partitions” section, the mount command is never even attempted (/sbin/mount.exfat-fuse never runs). So, it’s something in code that you guys have written that is breaking.
And, since that wasn’t working to do the mount, and you obviously didn’t spend any time figuring out why, you instead hard-coded everything into a special case “if” in a shell script that works absolutely fine if called from the “mount” command reading fstab, since it just passes the command line to the real mount helper binary.
Further testing shows that an “automount_options” line with any content at all (even something as innocuous as “rw”) causes the mount command to never happen. So, that’s where you need to start debugging this issue. I don’t have an SD card with NTFS or vFAT to check if those are broken, too, but I suspect that since those sections have “automount_options” lines, they might be.
It’s quite messy, and part of that is because of how UDisks is structured.
A couple of years ago the plan was to move to use udevil, but this also proved to have limitations that did not resolve the situation. It needs a revisit and some thoughts. I’m not keen on the whole Javascriptisation of UDisks2 and PolKit now. Perhaps something more minimal and fitting for OSMC is appropriate.
Filesystems like exfat, fat32 and ntfs that don’t natively support unix permissions cannot have their permissions changed by chmod - and that includes the mountpoint directory itself. So your chmod will do nothing.
They can only be set at mount time using mount options, and apply to the mount point as well as all files/directories beneath it.
Not sure what you’re trying to say here - the problem with exfat lies with the udisks binary itself, which has hard coded mount options in the source code, which are not suitable. It ignores the mount options passed to it via udisks-glue.conf for exfat partitions.
So our choices were to fork udisks and build our own copy of udisks with custom patches instead of using the upstream debian version, or create a simple wrapper script /sbin/mount.exfat-fuse to work around this.
This was done as part of the following commit two years ago:
As we were planning to migrate to udevil at the time the effort of having to fork udisks, make significant source changes to it, and seamlessly migrate users from the upstream packages to our own versions in place was deemed not to be worth the effort when udisks 1 is a dead end.
Ironically, moving from Jessie to Stretch this month has required us to build and package our own version of udisks as Debian no longer contains any udisks 1 packages. So in theory we could now remove this wrapper script and patch the source code directly to fix the handling of exfat partitions within udisks and make it support options passed from udisks-glue.conf, but again, udisks 1 is a dead end so it’s not worth the development time spent to fix this especially when users would not notice any real difference.
Our long term goal is still to move to udevil and write our own custom version of devmon, and doing so provide plenty of flexibility and customizability for end users, as well as allowing for “hook” scripts to run custom user actions when new volumes are mounted/unmounted etc.
This will be far more flexible than the very rigid and unforgiving syntax in udisks-glue.conf.
No, it’s a bug/limitation in the udisks binary. Have a look at the source. We are having to work around many bugs and limitations in the udisks binary that would need a significant rewrite of udisks to fix, and it simply isn’t worth the time and effort when udisks 1 is long abandoned.
Who are you to say we didn’t spend any time “figuring out why” it didn’t work ? We actually spent a lot of time on this and we know exactly why it didn’t work. Check the udisks-glue source and you’ll see that the mount options for exfat are hard coded.
auto_mount options in udisks-glue.conf will only accept specific options for each given file system type. If any are added that aren’t supported for that file system type based on a whitelist udisks has in the source, the whole line is ignored. This is a limitation of the udisks binary. Check the source…
There is no debugging to be done - udisks 1 is old, end of line, unsupported code that is full of limitations and known bugs. It also has a race condition that intermittently causes some drives not to mount reliably every time because it polls the kernel for information about the drive before all the information such as partition types etc is available - this causes it not to match any of the matches and fall through to the default option when it shouldn’t.
That’s why the logging is there in the default option - to capture information in the debug log about partitions/drives that did not correctly match the rules so that this problem could be diagnosed in the first place. (It is extremely hard to reproduce)
You can be critical all you like but the fundamental problem is that udisks 1 is creaky, buggy software which short of a major rewrite, has required many, many workarounds to get functioning in an acceptable state, and switching to udisks 2 is not feasible at the moment as Kodi does not properly integrate with it.
The real solution is to switch to udevil however there are still some integration issues between udevil and Kodi that caused it to be put on the backburner, as well as devmon having a few limitations, so to switch over will require some patches to Kodi as well as a rewrite of devmon both of which take significant time and effort.
Untested software deserves nasty comments, whether free or not. Other distributions don’t have this problem with automount disks.
I’m not about to spend hours scanning the source code for the helper service for a fatal bug in parsing the config file and passing the info to the mount command. Somebody far more familiar with the code should find the error in a few minutes.
If that were the only problem, it would at least mount the disk. Instead, the mount command is never called if those options are set. So, udisks-glue has some breakage in it somewhere.
Maybe it is the udisks binary that’s the problem, but that’s custom for OSMC, based on the packages. So, somewhere, there’s a disconnect that causes no mount to even be tried.
Nope, that’s not what’s happening. The line isn’t being ignored…it’s causing the mount to never happen, and an error is returned by udisks. Run it manually and see.
So, there are a lot of options you haven’t tried.
Just changing those hard-coded “fails” to at least mount and ignore would be a pretty easy fork, and likely accepted upstream. At least then a bad edit of udisks-glue.conf won’t silently fail the mount. Or, you could go whole hog and allow any mount options that the back-end mounter supports. Again, this would likely be accepted upstream, and you wouldn’t have to keep supporting it.
Use udev rules to allow the options in udisks-glue (or some other config file) to make it work.
Switch to something like autofs, that doesn’t have this problem.
So, no, I really don’t think you have done that much work on this. If it weren’t such a nasty security issue, I wouldn’t really care as much as I do, sinceI could solve it for myself with fstab or other options. But, all those people who buy a Vero box and plug in a USB stick or SD card, those are the ones you need to fix it for.
If you want ACLs and proper permissions, you should not use exFAT, FAT32 or NTFS on Linux. For those keeping media permanently attached to Linux devices, we indeed advise otherwise.
Out of curiosity, which distribution do you use, if you use Linux on another machine, what auto-mounting implementation is used there?
In Ubuntu (granted, hardly an epitome); I believe exFAT is still not even part of the distribution by default. Inserting an exFAT formatted device will greet you with a UDisks2 error. When you do install FUSE packages, the permissions are not secure.
The crux of the problem is you have no ACL permissions to map to. Maybe one day we’ll see permissions in attributes and respect of this with Unix tools. For now, we don’t.
I remember when @DBMandrake did the work on this. He spent countless hours testing multiple use cases and checking corner cases, including exFAT (it’s not commonly used on OSMC); making sure we could treat every filesystem OSMC supported in the best way possible, given the userspace tools we had. I’d wager that he has forgotten more than you know about automounting on Linux.
We always appreciate feedback, but the tone needs winding down. Some of these posts seem like a dick (or button) measuring competition. We are far more interested in the technical discussion and resolution of these issues. We’ll rewrite the disk mounter in the near future. We’ll do so to make sure people can practically use their devices: so that there is a good balance of security within the context of ACL control that these filesystems provided and a good balance of convenience.
Yes it does - I already said that udisks and udisks-glue have some significant bugs and limitations.
This is one of them - if you provide it with any mount options in udisks-glue.conf that it is not happy with for a given filesystem it will not attempt to mount it at all, it doesn’t just ignore the mount options it doesn’t like.
This is the main reason why there is so much special casing for each different filesystem type in udisks-glue.conf at the moment - to work around these limitations in the udisk/udisks-glue binaries, and also one of the major reasons why we want to replace it entirely and not expend any more effort on flogging a dead horse.
It is the binaries that are the problem - they are not “custom” for OSMC, we are simply building the last release of udisks and udisks-glue as-is from source and packaging them. We are only doing this because they were removed in Debian stretch so it was the only way to provide continuity of automounting to users during the stretch upgrade when we are not ready to switch to an alternative automounter at this time.
So any bugs and limitations in “our” version of udisks/udisks-glue are the same bugs and limitations that were in the Debian Jessie versions that we were using before. Again, because we want to switch away from udisks1 we are not expending any effort attempting to patch the source as it needs a big rewrite not minor patching.
Have you studied the source code to see how udisks-glue.conf is parsed and how it deals with unsupported mount options ? If not you’re just making wild guesses.
It won’t be accepted upstream because nobody is maintaining udisks1 anymore - it is an abandoned project and isn’t even present in Debian Stretch and will not be coming back.
And as said we aren’t going to spend any time flogging a dead horse. Even if we fix these specific bugs you still have the issue that the whole structure of udisks-glue.conf is too rigid and inflexible, which should be apparent by the amount of code duplication we’ve had to do as it doesn’t support multiple matches or falling through to anything other than a default action for example.
It also doesn’t make it feasible to provide true user modifiable hooks - we would love the new automounter to break out all the post mount and pre-unmount actions as separate user modifiable scripts that allow you to perform arbitrary actions when a device is mounted - such as restarting nfsd. Udevil/devmon can do this, udisks1 cannot.
I don’t even understand what you’re suggesting here, udev rules are only responsible for filtering the device and partition attachment events that udisks-glue monitors for, it can’t do anything to work around hard coded decisions in the udisks-glue source code.
What is the “nasty security issue” you are claiming ? Fat32/NTFS/Exfat partitions don’t have any user/group permissions that can be mapped into a unix permissions set - so there is no choice but to allow access to all users for these drives, if you expect anything to work.
The fact that you thought you should be able to chmod the mount point of an exfat drive after it is already mounted suggests that you don’t understand how linux treats permissions on these kind of drives.
If you want finer grained control of permissions on an external drive, format it as ext4 - it’s as simple as that. If “security” of those files is important to you you shouldn’t be using exfat in the first place.
Any world-writable directory that doesn’t have the sticky bit set is an “accelerator” for any other security hole that might exist on the system.
Since everything important concerning files in OSMC happens under the osmc user, there is no reason to have mounted directories owned by osmc to be world-writable. Although this really should be fixed at the udisks level, changing /sbin/mount.exfat to not allow world write should keep most users safe. Since this is part of a package controlled by osmc, it shouldn’t be that hard to fix.
I didn’t “think” that until I saw that udisks-glue.conf tried to do just that. I assumed that since you guys wrote that file, you knew what you were doing.
Except… the sticky bit is only usable on a filesystem which actually supports user and group ownership of files, which fat32, exfat and ntfs mounted on Linux do not.
The sticky bit prevents a file created by one user being deleted by another user who also has write access in the directory. But when you mount fat32/exfat/ntfs on Linux, you specify the “owner” and “group” for all files present and future on the volume at mount time.
And when you then write a file to that mounted volume it doesn’t matter what user you are when you write it - it will always appear to be owned by the same user who mounted the drive in the first place - because these file systems do not have a concept of user and group for files. Technically NTFS can support ownership of files but not in a way that is compatible with mounting the drive using fuse on Linux and of course exfat and fat32 have no concept of ownership of files at all.
So say the drive is mounted as the osmc user (which it is) then all files will appear to belong to that user. If you now create another user account called deluge and write files to the drive as this user the other and group permissions configured at mount time control whether you are allowed to read and write, however unlike a true unix filesystem the files you create will still be owned by the osmc user once they are written, not by the deluge user.
Consequently the sticky bit doesn’t help you because all files are always indicated as belonging to the same user no matter what user wrote them.
Nice try, but try again.
You are making an assumption that nobody would try to access external mounted drives as a user other than osmc. This is false.
Many users set up additional user accounts for software such as deluge or sickrage to run under to provide some isolation - for example the osmc user has sudo rights without a password however additional accounts created do not.
The reason why the automounter permissions for fat32/exfat/ntfs drives were changed is because users who were trying to do this found their additional user accounts had no access to automounted fat32/exfat/ntfs drives. We didn’t make the change for no reason.
There is one use of chmod in udisks-glue.conf - you’ll note that it is for the “other-partitions” match. Which means it does not match or get executed on vfat (fat32) or ntfs partitions.
As udisks-glue doesn’t handle exfat correctly we didn’t bother to add an explicit match for exfat in udisks-glue.conf, permissions there are handled by the previously discussed wrapper, so the chmod does run for exfat, but harmlessly as it effectively does nothing.
The chmod is actually there for ext4 (and similar unix file systems) to make the mount point user/group/other readable and writeable.
The reason for that is pretty simple - a freshly formatted ext4 volume has permissions that only allow root to read and write it. So if a user formats an external drive ext4 and then plugs it in it will get mounted with permissions that don’t allow the osmc user to read or write to the drive at all.
This was a relatively large support burden so we made the decision that the root directory of an external automounted ext4 partition should be user/group/other readable and writeable so it will “work out of the box”. Of course any directories within the mounted drive can have any permissions or ownership as desired if you want to secure individual directories. It’s only the top level of the external drive we touch with chmod.
While it makes sense for the top level root directory on a linux system to be writeable only by root (you don’t want normal users messing around at /) it doesn’t make sense for an external drive mounted further up the filesystem hierarchy such as /media/MYVIDEOS to only be readable/writeable by root when Kodi runs as osmc.
I know you think we’re pretty stupid, but we’ve thought all this through pretty carefully…
