muont(1) does not support cap_sys_admin

muont(1) does not support cap_sys_admin

[Renzo Davoli]

mount command does not seem to support the cap_sys_admin capability.

In fact the command fails when the mount system call would succeeds
for operation permitted to users (e.g. bind mounts in user-namespaces)

For example using userbindmount
https://github.com/rd235/userbindmount

$ userbindmount -s --
$ mount --bind /tmp/resolv.conf /etc/resolv.conf 
mount: only root can use "--bind" option
$ busybox mount --bind /tmp/resolv.conf /etc/resolv.conf 
$

As it can be seen from the example above, busybox mount
succeeds on the same command where mount(1) fails.

"Mount" erroneously checks that the effective user is root
and returns an error prior to invoke the system call mount(2),
forbidding in this way permitted operations.

thank you

	renzo

mount(8) does not support cap_sys_admin

[Renzo Davoli]

mount command does not seem to support the cap_sys_admin capability.

In fact the command fails when the mount system call would succeeds
for operation permitted to users (e.g. bind mounts in user-namespaces)

For example using userbindmount
https://github.com/rd235/userbindmount

$ userbindmount -s --
$ mount --bind /tmp/resolv.conf /etc/resolv.conf 
mount: only root can use "--bind" option
$ busybox mount --bind /tmp/resolv.conf /etc/resolv.conf 
$

As it can be seen from the example above, busybox mount
succeeds on the same command where mount(8) fails.

"Mount" erroneously checks that the effective user is root
and returns an error prior to invoke the system call mount(2),
forbidding in this way permitted operations.

thank you

	renzo

PS: I am sorry my previous mail had typos in the subject

Re: mount(8) does not support cap_sys_admin

[Karel Zak]

On Tue, Aug 22, 2017 at 10:40:11AM +0200, Renzo Davoli wrote:
> mount command does not seem to support the cap_sys_admin capability.
> 
> In fact the command fails when the mount system call would succeeds
> for operation permitted to users (e.g. bind mounts in user-namespaces)
> 
> For example using userbindmount
> https://github.com/rd235/userbindmount
> 
> $ userbindmount -s --
> $ mount --bind /tmp/resolv.conf /etc/resolv.conf 
> mount: only root can use "--bind" option
> $ busybox mount --bind /tmp/resolv.conf /etc/resolv.conf 
> $
> 
> As it can be seen from the example above, busybox mount
> succeeds on the same command where mount(8) fails.
> 
> "Mount" erroneously checks that the effective user is root
> and returns an error prior to invoke the system call mount(2),
> forbidding in this way permitted operations.

Well, historically mount(8) is not about mount(2) syscall only. It
also check filesystem type (read from devices), write userspace files
(/etc/mtab or /run/mount/utab), create loop devices, call btrfs
ioctls and execute mount helpers.

We can improve libmount to accept capabilities for simple use-cases
like --bind, but the question is if it does make sense if for another
tasks it will be hard to use. 

Frankly, I have never tried it. Maybe it will not so big issue to try
it, test it and describe possible limitation in the man page. I'll add
this to our TODO list.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: mount(8) does not support cap_sys_admin

[Alexey Gladkov]

On Tue, Aug 22, 2017 at 11:15:38AM +0200, Karel Zak wrote:
> On Tue, Aug 22, 2017 at 10:40:11AM +0200, Renzo Davoli wrote:
> > mount command does not seem to support the cap_sys_admin capability.
> > 
> > In fact the command fails when the mount system call would succeeds
> > for operation permitted to users (e.g. bind mounts in user-namespaces)
> > 
> > For example using userbindmount
> > https://github.com/rd235/userbindmount
> > 
> > $ userbindmount -s --
> > $ mount --bind /tmp/resolv.conf /etc/resolv.conf 
> > mount: only root can use "--bind" option
> > $ busybox mount --bind /tmp/resolv.conf /etc/resolv.conf 
> > $
> > 
> > As it can be seen from the example above, busybox mount
> > succeeds on the same command where mount(8) fails.
> > 
> > "Mount" erroneously checks that the effective user is root
> > and returns an error prior to invoke the system call mount(2),
> > forbidding in this way permitted operations.
> 
> Well, historically mount(8) is not about mount(2) syscall only. It
> also check filesystem type (read from devices), write userspace files
> (/etc/mtab or /run/mount/utab), create loop devices, call btrfs
> ioctls and execute mount helpers.
> 
> We can improve libmount to accept capabilities for simple use-cases
> like --bind, but the question is if it does make sense if for another
> tasks it will be hard to use. 
> 
> Frankly, I have never tried it. Maybe it will not so big issue to try
> it, test it and describe possible limitation in the man page. I'll add
> this to our TODO list.

This issue makes it impossible to use this libmount when you create a new
container. I mean that once you create namespace you can't mount /proc,
/sys, etc. Therefore, the parsing of the flags and checks you have to do
manually, rather than use an existing library.

-- 
Rgrds, legion

Re: mount(8) does not support cap_sys_admin

[Renzo Davoli]

On Tue, Aug 22, 2017 at 11:15:38AM +0200, Karel Zak wrote:
> I'll add this to our TODO list.

Thank you. Maybe I can help, proposing patches to support this feature.

renzo

Re: mount(8) does not support cap_sys_admin

[Karel Zak]

On Tue, Aug 22, 2017 at 12:31:58PM +0200, Alexey Gladkov wrote:
> On Tue, Aug 22, 2017 at 11:15:38AM +0200, Karel Zak wrote:
> > On Tue, Aug 22, 2017 at 10:40:11AM +0200, Renzo Davoli wrote:
> > > mount command does not seem to support the cap_sys_admin capability.
> > > 
> > > In fact the command fails when the mount system call would succeeds
> > > for operation permitted to users (e.g. bind mounts in user-namespaces)
> > > 
> > > For example using userbindmount
> > > https://github.com/rd235/userbindmount
> > > 
> > > $ userbindmount -s --
> > > $ mount --bind /tmp/resolv.conf /etc/resolv.conf 
> > > mount: only root can use "--bind" option
> > > $ busybox mount --bind /tmp/resolv.conf /etc/resolv.conf 

I try to play with this finally and I'm not sure if I follow you.

You have user namespace, why do you NOT map your euid to root?

 $ echo "nameserver 9.9.9.9" > /tmp/resolv.conf
 $ unshare --mount --user --map-root-user
 # mount --bind /tmp/resolv.conf /etc/resolv.conf
 # cat /etc/resolv.conf
 nameserver 9.9.9.9

your userbindmount map user to user, what is the advantage?

> > Frankly, I have never tried it. Maybe it will not so big issue to try
> > it, test it and describe possible limitation in the man page. I'll add
> > this to our TODO list.
> 
> This issue makes it impossible to use this libmount when you create a new
> container. I mean that once you create namespace you can't mount /proc,
> /sys, etc. Therefore, the parsing of the flags and checks you have to do
> manually, rather than use an existing library.

You can do what you want to do if you're root in your user namespace.

I'm not sure what is expected from mount/libmount in regard to
CAP_SYS_ADMIN. The reason why euid=0 is required by mount(8) is that
years ago some people have installed non-suid mount(8) with
CAP_SYS_ADMIN. 

See http://github.com/karelzak/util-linux/commit/0959f8063bf9b4d576822fe742a2bc9f5d1d1dbc

Unfortunately, this CAP is lightweight version of suid, so we really
don't want to close eyes and follow user wishes... I guess we still
need to verify things against fstab etc.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com