[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