[PATCH 2/2] mount: -T OTHERTAB support

Isaac Dunham ibid.ag at gmail.com
Sun Mar 15 05:01:59 UTC 2015


On Sun, Mar 15, 2015 at 02:43:15AM +0100, Harald Becker wrote:
> Hi Isaac,
> 
> the fstab approach has one big cave-eat, which got me awy from that idea: he
> format of fstab does not allow to specify the owner, group and permissions
> of newly created mount points, but if you like / need to do some kind of

Do you mean as in the permissions of the root of the mount:

mount -o uid=xxxx,gid=xxxx,mode=0700

or as in the permissions of the mountpoint itself, as entered in the 
filesystem where it's found:

mount -o x-mount.mkdir=0700

which is always root:root since it is disallowed for non-root users, but
does *not* affect the permissions or ownership of the filesystem that is
mounted there.
In fact, you can create a mode 0000 directory and mount a user-accessible
filesystem there.

I will readily admit that most of that may not be something that many
people can come up with off the top of their head. I happen to have 
just spent a large part of the day reading up on that sort of thing.

Note the x-mount.mkdir option isn't supported by Busybox yet; I've looked
at the code but haven't figured out how to do it yet.
(We also need to ignore x-* other than that, just to handle fstab properly.)

> restriction management, you always need to do some extra work to setup this
> information, but this scatters around the information into separate places
> :(  
> 
> So how does your fstab approach may help to fix this problem?

Between uid/gid/mode and x-mount.mkdir, you can do a lot.
To deal with message queues (no /dev/mqueue in Jessie OOTB),
I'd just add this line to /etc/vfstab below /dev:

mqueue	/dev/mqueue	mqueue	x-mount.mkdir=1300	0 0

And it should show up properly, rw, sticky bit set, ...

Mode 1300 would mean that no files are allowed to be created there
before mounting/after unmount, but root has permissions to check its
contents (despite being able to do so anyhow).
The sticky bit being set is typically a good thing, but probably
meaningless here.

On a typical system, this would be done by hand, with a service file
or adding "mkdir /dev/mqueue && mount -t mqueue /dev/mqueue" to a
script.

> ... beside that i think it's always a good idea to have the possibility to
> overwrite the name of the default table (e.g. when your root file system
> including etc is read only).

That's a very good point, which I had not thought about.

Thanks,
Isaac Dunham


More information about the busybox mailing list