If it makes sense for udisks2 to apply this option, you could also argue that it makes sense for mount(8), or, heck, even the kernel to do this. So I'm reassigning to util-linux since I don't think udisks should be in the business of deciding something that should be a sane default.

Hmm, now that I've read the summary more closely, I actually think this should be closed NOTABUG.

IOW, we shouldn't be trying to "guess" things here and just because you mount things through udisks doesn't really change anything - all it means is that you clicked an icon instead of typing 'mount' into a terminal.

If the selinux stuff in some filesystem on a disk is broken, well, the answer is to either fix it (run some selinux tool on it) or to add an /etc/fstab entry for the device where you can add the option context="system_u:object_r:removable_t:s0".

But as I said in comment 1, this is not really specific to udisks2 so I'm leaving it assigned to util-linux...

I don't agree with that. If I use cmdline or fstab, I am root, I know what I am doing and I don't want some stupid daemons guess what's best.

On the other side if I just use an external drive to share things between computers at home, then it is another story. Sure it is not too bad on one HDD if there are only a few machines to use it on. fstab could work. But ext4 is a nice FS to use on external drives and current situation is not usable in general.
At the moment users are stuck to FAT32 because NTFS is slow and ext4 is a problem because of selinux. If we want to have linux ussers comfortably use good filesystems then we have to have it usable.

IMHO adding the context= mount option as I request is no different from adding nosuid, nodev, etc. options that already are added by udisks2.  In a perfect world, one could select desired options from GUI or at least a config file but first we can have sane extX defaults. Hell, I lost a lot of time to figure out how to mount the drive so I can do anything with it at all. How many users can figure it out at all? Or do we just ask them to disable selinux?

Regards.

I agree that automatically guess that "some weird selinux context" on some device is unwanted sounds like a bad idea. 

The another tricky thing is detect that the device is removable (yes, we a flag for the device in /sys, but it's not too reliable and almost all devices are hot-plug/removable in these days).

If you don't like any selinux context than you can add the context= to your fstab or fix the context on the device ... so, NOTABUG from my point of view.

CC dwalsh, any comment or suggestion?

My proposal is to use the same mechanism that let us know the user can mount a device. That's why I initially filed the bug with udisks2.

In summary:
1. udisks2 knows that a device can be mounted by a particular local user
2. *something* sets options like nosuid and nodev (udisks2 ?)
3. that *something* should mount filesystem in a way user can access the data
3.1. alternatively that *something* should allow overriding mount options

At the moment ext4 cannot be used conveniently to share files with other linux users like fat32 and ntfs are. Or please let me know if ext4 filesystem can be created in such a way that is works wrt security like fat32.

Regards,
Aleksandar

What error are you seeing about a user not able to read a device?  We had a bug in an earlier policy where we were blocking unconfined_t from reading files with no labels on them. (file_t)  But that has been fixed.

I would prefer not to put any labels by default and agree with David.  That way a user could label content as httpd_sys_content_t and the apache server could read it. Having the system arbitrarily changing the label on the device is not a good idea.   And the removable_t stuff should probably be removed.  I think that is ancient stuff.

Thinking about it I can agree that no default settings can possibly fit all needs. In the true spirit of opensource, only giving the user flexibility to select more options during mount can make gui mounting a viable option.

I say it again. At the moment the best FS for just sharing files between heterogeneous machines is FAT32. I hoped somebody would be able to make it possible to do so with ext4 that does not lack so severely like the old FAT32. Right now using ext4 requires an advanced user with root access to the machine.

And I still think that the default option needs to be to ignore selinux labels on removable media, covering the most common use case. Running a http server is not what the average user does on removable media especially. It's just following what we do on fat32 and ntfs.

Regards.

Why would the user need Root access.  If the usb device is inserted and has ext4 it will either have labels or not.  The default user will be labeled unconfined_t is is able to do anything he wants with any label, now that the bug is fixed.

So sharing between systems which support the ext4 file system should work in a default SELinux environment, without having to use mount options.

Well, I just put connected in the machine a drive that contained my back-ups to migrate stuff to new machine and I couldn't even list content being root. Filesystem and back-ups were created on a debian box with selinux disabled. I'm also using an OpenWRT router as NAS.
I'm personally pretty much covered with fstab because I have only a few machines to care about. I think though that users trying to share files with ext4 will hit weird problems.

I wish there was a way to mount a drive just like fat32 with no user/group information and selimux. Just simple media files sharing. ATM I have some troubles sharing and backing up personal photos, clips and music.

I think you got burnt by the bug in policy where unconfined_t was not able to read unalabeled files.  I believe if you tried it again with the current policy, and no context mount, everything would work.