* getting rid of "mount: only root can ..."
@ 2014-05-01 23:37 Andy Lutomirski
2014-05-02 22:21 ` Dale R. Worley
0 siblings, 1 reply; 9+ messages in thread
From: Andy Lutomirski @ 2014-05-01 23:37 UTC (permalink / raw
To: util-linux
This isn't really true any more. Can we get rid of those checks or at
least have an option to turn them off?
--
Andy Lutomirski
AMA Capital Management, LLC
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: getting rid of "mount: only root can ..."
2014-05-01 23:37 getting rid of "mount: only root can ..." Andy Lutomirski
@ 2014-05-02 22:21 ` Dale R. Worley
2014-05-02 22:36 ` Andy Lutomirski
0 siblings, 1 reply; 9+ messages in thread
From: Dale R. Worley @ 2014-05-02 22:21 UTC (permalink / raw
To: Andy Lutomirski; +Cc: util-linux
> From: Andy Lutomirski <luto@amacapital.net>
>
> This isn't really true any more. Can we get rid of those checks or at
> least have an option to turn them off?
My understanding is that whether the user has to be root when running
mount depends on the "user" and "users" options in fstab. I assume
that "those checks" haven't changed recently because the required
behavior hasn't changed recently.
Dale
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: getting rid of "mount: only root can ..."
2014-05-02 22:21 ` Dale R. Worley
@ 2014-05-02 22:36 ` Andy Lutomirski
2014-05-05 22:50 ` Dale R. Worley
0 siblings, 1 reply; 9+ messages in thread
From: Andy Lutomirski @ 2014-05-02 22:36 UTC (permalink / raw
To: Dale R. Worley; +Cc: util-linux
On Fri, May 2, 2014 at 3:21 PM, Dale R. Worley <worley@alum.mit.edu> wrote:
>> From: Andy Lutomirski <luto@amacapital.net>
>>
>> This isn't really true any more. Can we get rid of those checks or at
>> least have an option to turn them off?
>
> My understanding is that whether the user has to be root when running
> mount depends on the "user" and "users" options in fstab. I assume
> that "those checks" haven't changed recently because the required
> behavior hasn't changed recently.
Blech. I forgot that mount is setuid root.
What if mount determined that the requested option wasn't allowed by
fstab and instead fell back to dropping privileges and trying anyway?
--Andy
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: getting rid of "mount: only root can ..."
2014-05-02 22:36 ` Andy Lutomirski
@ 2014-05-05 22:50 ` Dale R. Worley
2014-05-05 22:58 ` Andy Lutomirski
0 siblings, 1 reply; 9+ messages in thread
From: Dale R. Worley @ 2014-05-05 22:50 UTC (permalink / raw
To: Andy Lutomirski; +Cc: util-linux
> From: Andy Lutomirski <luto@amacapital.net>
> 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.
What I was thinking is that, in the best of all worlds, if mount
doesn't permit the requested operation, it should correctly report the
test that failed. For instance, sometimes only root may perform the
operation, and so mount should say
"mount: only root can ..."
But if members of group 'foo' are permitted, then it should say
"mount: only members of 'foo' and root can ..."
etc.
Dale
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: getting rid of "mount: only root can ..."
2014-05-05 22:50 ` Dale R. Worley
@ 2014-05-05 22:58 ` Andy Lutomirski
2014-05-06 9:46 ` Karel Zak
0 siblings, 1 reply; 9+ messages in thread
From: Andy Lutomirski @ 2014-05-05 22:58 UTC (permalink / raw
To: Dale R. Worley; +Cc: util-linux
On Mon, May 5, 2014 at 3:50 PM, Dale R. Worley <worley@alum.mit.edu> wrote:
>> From: Andy Lutomirski <luto@amacapital.net>
>
>> 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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: getting rid of "mount: only root can ..."
2014-05-05 22:58 ` Andy Lutomirski
@ 2014-05-06 9:46 ` Karel Zak
2014-05-06 13:50 ` Dale R. Worley
0 siblings, 1 reply; 9+ messages in thread
From: Karel Zak @ 2014-05-06 9:46 UTC (permalink / raw
To: Andy Lutomirski; +Cc: Dale R. Worley, util-linux
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@alum.mit.edu> wrote:
> >> From: Andy Lutomirski <luto@amacapital.net>
> >
> >> 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@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: getting rid of "mount: only root can ..."
2014-05-06 9:46 ` Karel Zak
@ 2014-05-06 13:50 ` Dale R. Worley
2014-05-06 15:38 ` Andy Lutomirski
0 siblings, 1 reply; 9+ messages in thread
From: Dale R. Worley @ 2014-05-06 13:50 UTC (permalink / raw
To: Karel Zak; +Cc: luto, util-linux
> From: Karel Zak <kzak@redhat.com>
> 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 ;-)
Yeah, that's the only thing that will work well: Have mount(8) and
the kernel both know what the rules are and enforce them
consistently. And ideally, mount(8) should tell the user exactly what
the rule is that's being violated.
Dale
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: getting rid of "mount: only root can ..."
2014-05-06 13:50 ` Dale R. Worley
@ 2014-05-06 15:38 ` Andy Lutomirski
2014-05-08 21:01 ` Dale R. Worley
0 siblings, 1 reply; 9+ messages in thread
From: Andy Lutomirski @ 2014-05-06 15:38 UTC (permalink / raw
To: Dale R. Worley; +Cc: util-linux, Karel Zak
[-- Attachment #1: Type: text/plain, Size: 887 bytes --]
On May 6, 2014 6:50 AM, "Dale R. Worley" <worley@alum.mit.edu> wrote:
>
> > From: Karel Zak <kzak@redhat.com>
>
> > 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 ;-)
>
> Yeah, that's the only thing that will work well: Have mount(8) and
> the kernel both know what the rules are and enforce them
> consistently. And ideally, mount(8) should tell the user exactly what
> the rule is that's being violated.
>
A kind of hackish solution would be for mount --nopriv or whatever to drop
privileges immediately and stop enforcing any policy at all.
--Andy
[-- Attachment #2: Type: text/html, Size: 1210 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: getting rid of "mount: only root can ..."
2014-05-06 15:38 ` Andy Lutomirski
@ 2014-05-08 21:01 ` Dale R. Worley
0 siblings, 0 replies; 9+ messages in thread
From: Dale R. Worley @ 2014-05-08 21:01 UTC (permalink / raw
To: Andy Lutomirski; +Cc: util-linux, kzak
> From: Andy Lutomirski <luto@amacapital.net>
>
> A kind of hackish solution would be for mount --nopriv or whatever to drop
> privileges immediately and stop enforcing any policy at all.
Given what Karel has said, I'm not sure that would give the correct
behavior:
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.
Dale
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2014-05-08 21:01 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-05-01 23:37 getting rid of "mount: only root can ..." Andy Lutomirski
2014-05-02 22:21 ` Dale R. Worley
2014-05-02 22:36 ` Andy Lutomirski
2014-05-05 22:50 ` Dale R. Worley
2014-05-05 22:58 ` Andy Lutomirski
2014-05-06 9:46 ` Karel Zak
2014-05-06 13:50 ` Dale R. Worley
2014-05-06 15:38 ` Andy Lutomirski
2014-05-08 21:01 ` Dale R. Worley
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.