1

I need ordinary users to be able to mount /dev/loop0p1 and /dev/loop0p2 on my machine. /dev/loop0p1 is always going to be a FAT32 partition and loop0p2 - a ext3.

To that end, I have:

1) created directories /tmp/loop0p1 and /tmp/loop0p2 (in startup script, I know those disappear after reboot):

[root@machine tmp]$ ls -l
(...)
drwxrwxrwx 2 root       root       80 Jul 22 00:25 loop0p1
drwxrwxrwx 2 root       root       40 Jul 22 00:50 loop0p2

2) added the following lines to /etc/fstab:

/dev/loop0p1  /tmp/loop0p1  vfat defaults,loop,users,noauto  0 0
/dev/loop0p2  /tmp/loop0p2  ext3 defaults,loop,users,noauto  0 0

3) Now as an ordinary user I am able to mount them , no problem.

Problem is with permissions of the loop0p2 Ext3 partition - before the mount, as you can see above, the /tmp/loop0p2 mountpoint is has permissions '777', but after the 'mount /dev/loop0p2', thos suddenly magically change to '755':

[root@machine tmp]$ ls -l /tmp
(...)
drwxrwxrwx 2 user user 16384 Jan  1  1970 loop0p1
drwxr-xr-x 3 root root  1024 Jul 22 00:37 loop0p2

and, needless to say, my user cannot write anything inside the /tmp/loop0p2 mountpoint, which is useless.

Why do the permissions change and is there a ext3 mount option which would give me full access? gid, uid, umask all seem unsupported by this damn ext3!!

Leszek
  • 341
  • 2
  • 4
  • 12
  • 2
    Because it's just a mount point. Once you mount something else there, it takes the permissions from what's actually mounted. When it's not mounted, you have the permissions from the underlying directory. When you mount, you have the permissions from the root of the filesystem you just mounted. Fix your permissions after mounting it. –  Jul 22 '16 at 00:18
  • I've tried also `-o X-mount.mkdir=1777` which is supposed to help, but it does not :) It looks like it sets the mode before mounting the filesystem, not after. – dma_k Nov 19 '19 at 11:18

4 Answers4

1

Thanks for all the answers, I understand now the permissions of the mountpoint come from the mounted directory.

This thing is that what I am mounting is not a directory, but an image of a block device in a file. The point is to be able to create an image of a USB disk in memory (that's why we are mounting it to TMPFS in /tmp, that's much much faster than writing to an actual block device)

Normal users need to be able to run a script that does this.

So here's the big picture:

1) I create a mount point /tmp/loop0p1

2) I add the following to /etc/fstab (so that normal users can mount /dev/loop0p1):

/dev/loop0p1  /tmp/loop0p1  ext3 defaults,loop,users,noauto  0 0

I run the following script (simplified to show the essence of the problem):

#!/bin/sh

dd if=/dev/zero of=usb.img bs=1M seek=9 count=1

sfdisk usb.img << EOF 
,20480,83
EOF

losetup -P /dev/loop0 usb.img
sleep 2

mkfs.ext3 /dev/loop0p1

mount /dev/loop0p1
echo "loop0p1" > /tmp/loop0p1/p1.txt
umount /tmp/loop0p1

losetup -d /tmp/loop0

The script, as you can see, creates a empty 10MB file, sets up a Linux (type '83') partition in it, loop-mounts this to /dev/loop0, creates a Ext3 filesystem in it, then mounts that to /tmp/loop0p1, and attempts to write a file there.

The problem is that the script fails with 'Permission denied' trying to write the file to /tmp/loop0p1, and no wonder, because like I already said - when I mount, the permissions of /tmp/loop0p1 change to 755 root:root, so obviously as a normal user I cannot write anything to there.

The thing I am mounting is just created out of nothing by 'dd', 'sfdisk' and 'mkfs.ext3'. What exactly should I change so that the user who's been running the script actually has write access?

Leszek
  • 341
  • 2
  • 4
  • 12
0

You will have to manually give write permissions after mount.

chmod 777 /your directory

umask and rw will not work in ext file system.

Sachin Singh
  • 171
  • 1
  • 8
0

The issue here is that a mounted filesystem has its own permissions and will not inherit the permissions of the directory (or mountpoint) it is mounted to.

The solution is to set your permissions after the partition is mounted.

In order to do that you can use:

chmod 777 /tmp/loop0p2

However this may not fully resolve the issue since if you also have additional files within the mountpoint those will also retain their previous permissions so a more useful command for you may be:

chmod -R 777 /tmp/loop0p2

Alternatively - if only your user needs access to it - you could chown the files to just the user needing access:

chown <user>:<group> /tmp/loop0p2 [/ only]
chown -R <user>:<group> /tmp/loop0p2 [recursively]

Hope this helps!

Christopher Williamson
  • 9
  • 4
  • What ? `chmod -R 777 /tmp/loop0p2` why? that's rubbish. Why would (for example) text files on the filesystem need execute ? – user9517 Jul 22 '16 at 11:40
  • He mentioned it was a tmp partition so the permissions aren't greatly important. Generally I would say 755 for dirs and 644 for files but if this is a /tmp style mount it really doesn't matter a great deal since all users should have all access to all files and generally a tmp partition would be mounted with noexec anyway. – Christopher Williamson Jul 23 '16 at 11:54
  • The fstab entries are there too they lack noexec. Permissions are always important ... still a ridiculous answer. – user9517 Jul 23 '16 at 15:12
  • Ah, right, I see 'devops' ... it all falls into place. – user9517 Jul 23 '16 at 15:13
  • If wanting things to be correct rather than expedient is a terrible attitude then I'm comfortable with that. – user9517 Jul 24 '16 at 13:22
  • I wanted to take a moment to apologise for my previous response. You are indeed correct that the solution I offered was not best practice material and I should have taken the time to explain what the best practice for this kind of issue was. – Christopher Williamson Aug 07 '16 at 13:30
0

Actually there's an even simpler script that shows the problem.

We want to be able to run the following script as a normal user (as root it runs fine):

#!/bin/sh

dd if=/dev/zero bs=8192 count=128 of=disk.img
mkfs -t ext2 -F disk.img
losetup /dev/loop0 disk.img
mount /dev/loop0
echo aaaa > /mnt/aa
umount /mnt
losetup -d /dev/loop0

To that end, we

  • add appropriate entry to /etc/fstab that makes /dev/loop0 mountable to /mnt by all users (only then non-roots can mount)
  • add the user in question to the group that /dev/loop is owned by (in Fedora this is the 'disk' group, the point is so that the user can run 'losetup' )
  • run the script. You will get 'Permission denied' from 'echo'.
Leszek
  • 341
  • 2
  • 4
  • 12