4

Loop devices, i.e. for mounting raw disk images, can be managed without root privileges using udisks.

For testing purposes, an image can be created and formatted like so:

dd if=/dev/urandom of=img.img bs=1M count=16
mkfs.ext4 img.img

And then setup using udisks

udisksctl loop-setup -f img.img

This creates a loop device for the image and mounts it to a new directory under /run/$USER, just like any local hard drive managed by udisks. Only the permissions are not what I expected.

# ls -l /run/media/$USER/
drwxr-xr-x 3 root  root   1024 Apr 10 11:19 [some id]
drwx------ 1 auser auser 12288 Oct 30  2012 [a device label]

The first one listed is the loop device, owned by root and not writable by anybody else. The second one is a local hard drive or an USB pen device mounted for comparison, belonging to the user who mounted it. I know that I could fix this with a simple chmod executed as root.

But why does udisks assign different permissions and owners? Can it be configured to do otherwise?

5
  • belonging to the user who mounted it. - that right behavior, because opposite would be the user can assign any group-owner-permission to his files (which root do))
    – MolbOrg
    Apr 14, 2014 at 7:03
  • also suggests udisks-glue in similar situation, possible nice to give a shot for that tip.
    – MolbOrg
    Apr 14, 2014 at 7:11
  • @MolbOrg this is indeed the correct behavior which works with i.e. USB devices. But why does it not behave like this with an image?
    – XZS
    Apr 14, 2014 at 13:32
  • @MolbOrg I tried udisks-glue before but it seems to work only with udisks, not with udisks2. Is there a similar tool for the second version?
    – XZS
    Apr 14, 2014 at 13:33
  • interesting question things may be changed since that article was writtend, but maybe take looks for FUSE
    – MolbOrg
    Apr 15, 2014 at 19:18

1 Answer 1

4

I had a detailed look into the udisks2 source code and found the solution there.

The devices correctly mounted under user permissions were formatted with old filesystems, like fat. These accept uid= and gid= mount options to set the owner. Udisks automatically sets these options to user and group id of the user that issued the mount request.

Modern filesystems, like the ext series, do not have such options but instead remember owner and mode of the root node. So chown auser /run/media/auser/[some id] indeed works persistently. An alternative is passing -E root_user to mkfs.ext4 which initializes uid and gid of the newly created filesystem to its creator.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .