On Mon, May 05, 2014 at 03:58:50PM -0700, Andy Lutomirski wrote:
> On Mon, May 5, 2014 at 3:50 PM, Dale R. Worley <worley@xxxxxxxxxxxx> wrote:
> >> From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
> >
> >> What if mount determined that the requested option wasn't allowed by
> >> fstab and instead fell back to dropping privileges and trying anyway?
> >
> > I'm not envisioning the problem that you're addressing very well.
>
> If I set up a user namespace in which non-root users can call mount
> (the system call), it's annoying to work with because mount (the
> util-linux program) just assumes that uid != 0 means that mount won't
> work.
>
> The issue here is that there are two conflicting sets of policy: the
> in-kernel policy of who may mount/umount and the userspace policy of
> who may use the setuid mount tool to mount as euid == 0 despite their
> actual (kernel) privileges.
Andy is right, mount(8) is very paranoid when executed by non-root
users (sure, because it's suid almost everywhere).
I'll try to improve it to make it more usable with user namespaces.
The problem is that mount(8) is not just about mount(2) call only. If
we drop privileges then mount(8) will report problems with things like
FS detection, loopdevs setups, etc. It's necessary to review the code
and make errors/warnings somehow usable. ... added to my TODO for the
next week ;-)
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
