Bug 63849 - udisks2 mounts floppy disk as root
Summary: udisks2 mounts floppy disk as root
Status: NEW
Alias: None
Product: udisks
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: All Linux (All)
: medium normal
Assignee: David Zeuthen (not reading bugmail)
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-04-23 17:07 UTC by Wolfgang Bauer
Modified: 2016-02-27 16:49 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments
output of 'udisksctl dump' (33.49 KB, text/plain)
2013-04-23 17:07 UTC, Wolfgang Bauer
Details
output of 'udevadm info --export-db' (as root) (118.02 KB, text/plain)
2013-04-23 17:09 UTC, Wolfgang Bauer
Details
output of 'cat /proc/self/mountinfo' (3.92 KB, text/plain)
2013-04-23 17:10 UTC, Wolfgang Bauer
Details
Patch to try to mount filesystems as calling user first. (1.08 KB, patch)
2013-12-10 08:47 UTC, David Riebenbauer
Details | Splinter Review
[PATCH 1/2] Introduce new build dependency on libblkid (1.87 KB, patch)
2014-05-27 08:25 UTC, David Riebenbauer
Details | Splinter Review
[PATCH 2/2] Probe media that hasn't been probed by udev yet. (2.98 KB, patch)
2014-05-27 08:26 UTC, David Riebenbauer
Details | Splinter Review
[PATCH 2/2] Probe media that hasn't been probed by udev yet. (3.49 KB, patch)
2014-05-27 10:32 UTC, David Riebenbauer
Details | Splinter Review
[PATCH 2/2] Probe media that hasn't been probed by udev yet. (3.18 KB, patch)
2014-05-28 16:30 UTC, David Riebenbauer
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Wolfgang Bauer 2013-04-23 17:07:14 UTC
Created attachment 78381 [details]
output of 'udisksctl dump'

When I try to mount a floppy disk (formatted with FAT12) in the internal floppy drive using "udisksctl mount -b /dev/fd0" it gets mounted as root instead of the logged in user. As a consequence I don't have write access.

wolfi@amiga:~> udisksctl mount -b /dev/fd0
Mounted /dev/fd0 at /run/media/wolfi/disk.
wolfi@amiga:~> ls -la /run/media/wolfi/disk
insgesamt 86
drwxr-xr-x  2 root root  3584  1. Jän 1970  .
drwxr-x---+ 3 root root    60 23. Apr 18:07 ..
-rwxr-xr-x  1 root root 83968 16. Okt 2001  slides1.ppt


On the other hand, when I try to mount an USB stick (formatted with FAT32) it does get mounted as the logged in user.

wolfi@amiga:~> udisksctl mount -b /dev/sdc1
Mounted /dev/sdc1 at /run/media/wolfi/Transcend.
wolfi@amiga:~> ls -la /run/media/wolfi/Transcend
insgesamt 16
drwx------   3 wolfi users 8192  1. Jän 1970  .
drwxr-x---+  4 root  root    80 23. Apr 18:08 ..
drwx------  18 wolfi users 8192 27. Jän 23:45 Instrumentelle Analytische Chemie Protokolle

I would expect that the floppy disk is also mounted as the logged in user.

The same behaviour occurs with udisks-2.0.0 as shipped with openSUSE 12.3 and a self-compiled udisk-2.1.0.
I also tried an Ubuntu 13.04 LiveCD with the same result, so it's not openSUSE specific.

wolfi@amiga:~> cat /etc/fstab
/dev/sdb2            swap                 swap       defaults              0 0
/dev/sda1            /                    reiserfs   acl,user_xattr        1 1
proc                 /proc                proc       defaults              0 0
sysfs                /sys                 sysfs      noauto                0 0
debugfs              /sys/kernel/debug    debugfs    noauto                0 0
usbfs                /proc/bus/usb        usbfs   auto,busgid=110,busmode=0775,devgid=110,devmode=0664                0 0
devpts               /dev/pts             devpts     mode=0620,gid=5       0 0
/dev/sdb1            /windows/C           ntfs-3g    defaults              0 0

wolfi@amiga:~> rpm -q udisks2 gvfs libatasmart4
udisks2-2.0.0-5.4.1.x86_64
gvfs-1.14.2-2.1.2.x86_64
libatasmart4-0.19-2.1.1.x86_64
Comment 1 Wolfgang Bauer 2013-04-23 17:09:29 UTC
Created attachment 78382 [details]
output of 'udevadm info --export-db' (as root)
Comment 2 Wolfgang Bauer 2013-04-23 17:10:44 UTC
Created attachment 78383 [details]
output of 'cat /proc/self/mountinfo'
Comment 3 Wolfgang Bauer 2013-04-24 18:11:05 UTC
I just noticed that the floppy _is_ mounted as user when I specify the filesystem type with the -t option:

wolfi@amiga:~> udisksctl mount -b /dev/fd0 -t vfat
Mounted /dev/fd0 at /run/media/wolfi/disk.
wolfi@amiga:~> ls -la /run/media/wolfi/disk
insgesamt 86
drwx------  2 wolfi users  3584  1. Jän 1970  .
drwxr-x---+ 3 root  root     60 24. Apr 20:05 ..
-rw-r--r--  1 wolfi users 83968 16. Okt 2001  slides1.ppt

So the issue seems to be that udisks doesn't correctly identify the filesystem type.
Comment 4 David Zeuthen (not reading bugmail) 2013-04-24 20:17:05 UTC
(In reply to comment #3)
> I just noticed that the floppy _is_ mounted as user when I specify the
> filesystem type with the -t option:
> 
> wolfi@amiga:~> udisksctl mount -b /dev/fd0 -t vfat
> Mounted /dev/fd0 at /run/media/wolfi/disk.
> wolfi@amiga:~> ls -la /run/media/wolfi/disk
> insgesamt 86
> drwx------  2 wolfi users  3584  1. Jän 1970  .
> drwxr-x---+ 3 root  root     60 24. Apr 20:05 ..
> -rw-r--r--  1 wolfi users 83968 16. Okt 2001  slides1.ppt
> 
> So the issue seems to be that udisks doesn't correctly identify the
> filesystem type.

Well, we can't identify it ahead of time as it would create a lot of noise and there's no way to check if a new medium has been inserted. We should probably special-case /dev/fd* and always just assume that it's vfat...
Comment 5 Wolfgang Bauer 2013-04-24 22:18:29 UTC
(In reply to comment #4)
> 
> Well, we can't identify it ahead of time as it would create a lot of noise
> and there's no way to check if a new medium has been inserted.

Aha. Thanks for the explanation, makes sense.

> We should probably special-case /dev/fd* and always just assume that it's vfat...

Yes, I think that would be the best thing to do.

As it is now, you can't really use the floppy drive in graphical environments like KDE and GNOME, although they do have a nice floppy icon in their filemanagers...
Comment 6 Carlos Silva 2013-07-07 08:29:41 UTC
I'm having this exact same problem but with an ext4 partitioned disk. Ext4 partitions are just used on internal disks, they can be used on external ones too. But when this happens, this is the mounts I get:
/dev/sdc1 on /run/media/r3pek/6ef9a3f5-26fc-41eb-baa8-1f344b419725 type ext4 (rw,nosuid,nodev,relatime,data=ordered,uhelper=udisks2)
/dev/sdd1 on /run/media/r3pek/7E11-ECF4 type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=100,fmask=0022,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,

sdc is an external ext4 formated 1TB HD
sdd is a 1GB pen drive

both were user-mounted via udisks2 but it happens that the user can't create anything under sdc1's mount point, but it can on sdd1's. And this is why:
$ ls -lh /run/media/r3pek/
total 8.0K
drwxr-xr-x 4 root  root  4.0K Jul  3 17:55 6ef9a3f5-26fc-41eb-baa8-1f344b419725
drwx------ 7 r3pek users 4.0K Dec 31  1969 7E11-ECF4


Permissions should be enforced when creating the mountpoint, so that the owner of that directory is the user who requested the mount. Of course this should only be done for removable harddrives to prevent the user to mount the local filesystem and change anything in it.
Comment 7 David Riebenbauer 2013-11-19 10:58:08 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > I just noticed that the floppy _is_ mounted as user when I specify the
> > filesystem type with the -t option:
> > 
> > wolfi@amiga:~> udisksctl mount -b /dev/fd0 -t vfat
> > Mounted /dev/fd0 at /run/media/wolfi/disk.
> > wolfi@amiga:~> ls -la /run/media/wolfi/disk
> > insgesamt 86
> > drwx------  2 wolfi users  3584  1. Jän 1970  .
> > drwxr-x---+ 3 root  root     60 24. Apr 20:05 ..
> > -rw-r--r--  1 wolfi users 83968 16. Okt 2001  slides1.ppt
> > 
> > So the issue seems to be that udisks doesn't correctly identify the
> > filesystem type.
> 
> Well, we can't identify it ahead of time as it would create a lot of noise
> and there's no way to check if a new medium has been inserted. We should
> probably special-case /dev/fd* and always just assume that it's vfat...

What about trying to identify it, directly before the mount? Or is that what you meant anyway?
Comment 8 David Riebenbauer 2013-12-10 08:47:52 UTC
Created attachment 90559 [details] [review]
Patch to try to mount filesystems as calling user first.

This seems to be a regression, where udisks wouldn't try to mount filesystems as the calling user first. This can be tested with any entry with the user keyword and a fat filesystem. In my case an usb dongle.

UUID=10B3-837F /media/cruzer vfat rw,nosuid,nodev,relatime,user,showexec,utf8,errors=remount-ro 0 0

Mounting the device with udisks results in the filesystem mounted as root.

I've attached a patch to fix the problem. Please review.
Comment 9 Programmist11180 2014-02-22 13:02:33 UTC
Hello David.
This patch works only with this entry in /etc/fstab

/dev/fd0	/media/floppy0	auto  rw,user,noauto	0	0

this is a partial fix of a problem, as for usb floppy drives it is necessary to add record in fstab that is inconvenient for users.
Comment 10 David Riebenbauer 2014-05-27 08:25:43 UTC
Created attachment 99930 [details] [review]
[PATCH 1/2] Introduce new build dependency on libblkid
Comment 11 David Riebenbauer 2014-05-27 08:26:41 UTC
Created attachment 99931 [details] [review]
[PATCH 2/2] Probe media that hasn't been probed by udev yet.
Comment 12 David Riebenbauer 2014-05-27 08:29:08 UTC
(In reply to comment #9)
> Hello David.
> This patch works only with this entry in /etc/fstab
> 
> /dev/fd0	/media/floppy0	auto  rw,user,noauto	0	0
> 
> this is a partial fix of a problem, as for usb floppy drives it is necessary
> to add record in fstab that is inconvenient for users.

Alright, I've added two patches to use libblkid to probe for the filesystem prior to mounting it. These are supposed to be used in addition to the one before.

Please review.

Thanks,
David
Comment 13 David Riebenbauer 2014-05-27 10:32:23 UTC
Created attachment 99941 [details] [review]
[PATCH 2/2] Probe media that hasn't been probed by udev yet.

Sorry, forgot to rework error handling in the second patch before submitting.

Here's the correct version.
Comment 14 Programmist11180 2014-05-27 12:55:11 UTC
I applied these three patches.
Without entry in fstab: When I try to get into a floppy through Thunar it says: "Message did not receive a reply (timeout by message bus)." And service udisksd ends.
Comment 15 Wolfgang Bauer 2014-05-28 10:36:04 UTC
(In reply to comment #14)
> I applied these three patches.
> Without entry in fstab: When I try to get into a floppy through Thunar it
> says: "Message did not receive a reply (timeout by message bus)." And
> service udisksd ends.

I can confirm this problem here after applying the 3 patches to the current version 2.1.3.
Running "udisksctl mount -b /dev/fd0" with the removed fstab entry just gives:
Error mounting /dev/fd0: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus)

udisksd apparently crashes, it disappears from the process list temporarily, and is restarted again immediately.

With the following fstab entry in place it works and indeed mounts the disk as user, not root as before:
/dev/fd0             /media/floppy        auto       noauto,user,sync      0 0
Comment 16 Wolfgang Bauer 2014-05-28 10:48:27 UTC
I installed debuginfo packages now and attached gdb to udisksd, I get the following backtrace:
Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7fa21ffff700 (LWP 2865)]
0x00007fa230cae849 in raise () from /lib64/libc.so.6
(gdb) bt
#0  0x00007fa230cae849 in raise () from /lib64/libc.so.6
#1  0x00007fa230cafcd8 in abort () from /lib64/libc.so.6
#2  0x00007fa231297f0d in ?? () from /usr/lib64/libglib-2.0.so.0
#3  0x00007fa2312b52f7 in g_assertion_message ()
   from /usr/lib64/libglib-2.0.so.0
#4  0x00007fa2312b535a in g_assertion_message_expr ()
   from /usr/lib64/libglib-2.0.so.0
#5  0x000000000041fc05 in probe_fs_type_prior_to_mount (error=0x7fa21fffe778, 
    block=0x2510220) at udiskslinuxfilesystem.c:623
#6  calculate_fs_type (error=0x7fa21fffe778, given_options=0x25bb4d0, 
    block=<optimized out>) at udiskslinuxfilesystem.c:746
#7  handle_mount (filesystem=0x25102b0, invocation=0x7fa2240031c0, 
    options=0x25bb4d0) at udiskslinuxfilesystem.c:1448
...

So it seems to assert in udiskslinuxfilesystem.c:623, which is:
gassert (block == NULL);
Comment 17 David Riebenbauer 2014-05-28 16:30:29 UTC
Created attachment 100040 [details] [review]
[PATCH 2/2] Probe media that hasn't been probed by udev yet.

(In reply to comment #16)
> ...
> 
> So it seems to assert in udiskslinuxfilesystem.c:623, which is:
> gassert (block == NULL);

Yeah, that really should have been, (block != NULL). That should teach me not submit patches without reading over them a second time after a good night's sleep.

Anyway, thanks for testing the both of you, and sorry for crashing your udisks. I think this time I got it right.
Comment 18 Programmist11180 2014-05-29 16:19:28 UTC
OK, with updated patch it works. But there is a problem:

$ udisksctl mount -b /dev/fd0
Error mounting /dev/fd0: GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Failed to open device /dev/fd0 for filesystem probing.

$ udisksctl mount -b /dev/fd0
Mounted /dev/fd0 at /media/nikts/disk.

The diskette is always mounted only with the second attempt.
Comment 19 Wolfgang Bauer 2014-06-02 16:40:14 UTC
(In reply to comment #18)
> OK, with updated patch it works. But there is a problem:
> 
> $ udisksctl mount -b /dev/fd0
> Error mounting /dev/fd0: GDBus.Error:org.freedesktop.UDisks2.Error.Failed:
> Failed to open device /dev/fd0 for filesystem probing.
> 
> $ udisksctl mount -b /dev/fd0
> Mounted /dev/fd0 at /media/nikts/disk.
> 
> The diskette is always mounted only with the second attempt.

I can confirm this here: It works now, but only on second attempt when there's no fstab entry (with an entry it works immediately).

But I don't think this is related to the patch or udisks2.
I see the same behavior with "mdir". After inserting a new disk, "mdir" fails with:
Can't open /dev/fd0: No such device or address
Cannot initialize 'A:'
Running it a second time works. Also after running mdir once, "udisksctl mount" works and vice versa. So this rather seems to be a kernel issue I think.
Comment 20 Programmist11180 2014-06-02 17:20:21 UTC
> But I don't think this is related to the patch or udisks2.
> I see the same behavior with "mdir". After inserting a new disk, "mdir" fails with:
> Can't open /dev/fd0: No such device or address
> Cannot initialize 'A:'
> Running it a second time works. Also after running mdir once, "udisksctl mount" works and vice versa. So this rather seems to be a kernel issue I think.

Same behaviour on kernel 3.14.
Floppy mounts from the first attempt on a kernel 3.2.
Comment 21 David Riebenbauer 2014-06-03 11:36:53 UTC
(In reply to comment #20)
> > But I don't think this is related to the patch or udisks2.
> > I see the same behavior with "mdir". After inserting a new disk, "mdir" fails with:
> > Can't open /dev/fd0: No such device or address
> > Cannot initialize 'A:'
> > Running it a second time works. Also after running mdir once, "udisksctl mount" works and vice versa. So this rather seems to be a kernel issue I think.
> 
> Same behaviour on kernel 3.14.
> Floppy mounts from the first attempt on a kernel 3.2.

Thanks for testing.

I couldn't reproduce the problem here, but I'll try with a newer kernel next week. Unfortunately I only have access to an actual floppy drive about once a week.

BTW,  what kind of distribution and destop environment are you two using?
Comment 22 Programmist11180 2014-06-03 11:44:25 UTC
> BTW,  what kind of distribution and destop environment are you two using?

Debia Wheezy, XFCE.
Comment 23 Wolfgang Bauer 2014-06-04 19:50:11 UTC
(In reply to comment #21)
> BTW,  what kind of distribution and destop environment are you two using?
openSUSE 13.1 with kernel 3.11.10 and KDE 4.13.1 here.

> I couldn't reproduce the problem here, but I'll try with a newer kernel next
> week. Unfortunately I only have access to an actual floppy drive about once
> a week.

I can reproduce the issue (both) in VirtualBox with openSUSE Factory (kernel 3.14), so a physical floppy drive is not really necessary.

I will test with other kernel versions as well in the next days...
Comment 24 Programmist11180 2014-06-06 11:54:29 UTC
kernel 3.12.9.1 - works normally.
Comment 25 Programmist11180 2014-06-06 19:40:49 UTC
Kernel 3.13.10 - works normally.
Possibly it is regression in a kernel 3.14
Comment 26 Wolfgang Bauer 2014-06-07 09:57:41 UTC
(In reply to comment #24)
> kernel 3.12.9.1 - works normally.
(In reply to comment #25)
> Kernel 3.13.10 - works normally.

I tried some kernels as well, here are my findings:
It works fine (on first attempt) with the 3.7.10 kernels from openSUSE 12.3.

It still works fine with the 3.11.6 kernel shipped with openSUSE 13.1.
But it fails with the 3.11.10 kernels available in the official update repo.

Anyway, I guess you/we can stop trying different kernel versions now:
> Possibly it is regression in a kernel 3.14
This is the commit that causes it:
https://git.kernel.org/cgit/linux/kernel/git/axboe/linux-block.git/commit/?h=for-next&id=7b7b68bba5ef23734c35ffb0d8d82079ed604d33

I built openSUSE 13.1's 3.11.10 kernel (the latest one that has this problem) _without_ that commit (it was backported by openSUSE), and it works fine now.

Here is the accompanying bug report that lead to this commit:
https://bugzilla.novell.com/show_bug.cgi?id=773058

Not sure how to proceed now.
I think a bug report against the kernel would be in order, as this not only affects udisks.
(as mentioned, mdir and blkid show the same behavior)

I guess I'll start with reporting it to openSUSE, as they are "responsible" for that change.
But this will have to wait until after the weekend.
Comment 27 David Riebenbauer 2014-06-13 20:20:02 UTC
> Anyway, I guess you/we can stop trying different kernel versions now:
> > Possibly it is regression in a kernel 3.14
> This is the commit that causes it:
> https://git.kernel.org/cgit/linux/kernel/git/axboe/linux-block.git/commit/
> ?h=for-next&id=7b7b68bba5ef23734c35ffb0d8d82079ed604d33
> 
> I built openSUSE 13.1's 3.11.10 kernel (the latest one that has this
> problem) _without_ that commit (it was backported by openSUSE), and it works
> fine now.
> 
> Here is the accompanying bug report that lead to this commit:
> https://bugzilla.novell.com/show_bug.cgi?id=773058
> 
> Not sure how to proceed now.
> I think a bug report against the kernel would be in order, as this not only
> affects udisks.
> (as mentioned, mdir and blkid show the same behavior)
> 
> I guess I'll start with reporting it to openSUSE, as they are "responsible"
> for that change.
> But this will have to wait until after the weekend.

I've got to the same commmit by using 'git bisect' independently. I haven't looked into it yet, however. I guess a bug report to util-linux might be good too.
Comment 28 Wolfgang Bauer 2014-06-16 23:29:10 UTC
(In reply to comment #27)
> I've got to the same commmit by using 'git bisect' independently. I haven't
> looked into it yet, however. I guess a bug report to util-linux might be
> good too.

No need for any further bug reports.
This has been fixed already:
https://lkml.org/lkml/2014/5/28/297

It has been backported to openSUSE's 3.11.10 kernel and will be part of the next kernel update there.
I tried it out, and floppy disk access now works at first attempt again, be it with mdir, blkid, or the patched udisks (with or without an fstab entry for the floppy drive).

And yes, the patches still work fine and fix the issue reported here, i.e. the floppy does get correctly mounted as user, no matter whether there is an fstab entry or not.
Comment 29 David Riebenbauer 2014-06-20 10:04:34 UTC
Ah, cool. Thanks for monitoring the situation on that front.
Comment 30 beroal 2016-02-27 16:49:56 UTC
Is this patch in Udisks yet?


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.