2008-03-17 20:03:43

by Miklos Szeredi

[permalink] [raw]
Subject: [patch 00/11] mount ownership and unprivileged mount syscall (v9)

Andrew, Al,

Please consider adding this series to your trees.

I've been using these patches for a while on my laptop to mount fuse
filesystems as user, without any suid-root helpers. The setup is as
follows:

- link /proc/mounts to /etc/mtab
- patch util-linux-ng with http://lkml.org/lkml/2008/1/16/103
- remove suid from mount, umount and fusermount
- add a line to /etc/fstab to bind mount ~/mnt onto itself owned by the user
- add 'fs.types.fuse.usermount_safe = 1' to /etc/sysctl.conf

Apart from '/dev/sda2' being replaced with '/dev/root' in 'mount' and
'df' outputs, I haven't experienced any problems.

Thanks,
Miklos

v8 -> v9

- new patch: copy mount ownership when cloning the mount namespace

v7 -> v8

- extend documentation of allow_usermount sysctl tunable
- describe new unprivileged mounting in fuse.txt

v6 -> v7:

- add '/proc/sys/fs/types/<type>/usermount_safe' tunable (new patch)
- do not make FUSE safe by default, describe possible problems
associated with unprivileged FUSE mounts in patch header
- return EMFILE instead of EPERM, if maximum user mount count is exceeded
- rename option 'nomnt' -> 'nosubmnt'
- clean up error propagation in dup_mnt_ns
- update util-linux-ng patch

v5 -> v6:

- update to latest -mm
- preliminary util-linux-ng support (will post right after this series)

v4 -> v5:

- fold back Andrew's changes
- fold back my update patch:
o use fsuid instead of ruid
o allow forced unpriv. unmounts for "safe" filesystems
o allow mounting over special files, but not over symlinks
o set nosuid and nodev based on lack of specific capability
- patch header updates
- new patch: on propagation inherit owner from parent
- new patch: add "no submounts" mount flag

v3 -> v4:

- simplify interface as much as possible, now only a single option
("user=UID") is used to control everything
- no longer allow/deny mounting based on file/directory permissions,
that approach does not always make sense

v1 -> v3:

- add mount flags to set/clear mnt_flags individually
- add "usermnt" mount flag. If it is set, then allow unprivileged
submounts under this mount
- make max number of user mounts default to 1024, since now the
usermnt flag will prevent user mounts by default

--


2008-03-17 22:55:23

by James Morris

[permalink] [raw]
Subject: Re: [patch 00/11] mount ownership and unprivileged mount syscall (v9)

Something to consider down the track would be how to possibly allow this
with SELinux, which only knows about normal mounts.

We might need a user_mount hook which is called once the core kernel code
determines that it is a a valid unprivileged mount (although the sb_mount
hook will already have been called, IIUC).


- James
--
James Morris
<[email protected]>

2008-03-18 11:34:33

by Miklos Szeredi

[permalink] [raw]
Subject: Re: [patch 00/11] mount ownership and unprivileged mount syscall (v9)

> Something to consider down the track would be how to possibly allow this
> with SELinux, which only knows about normal mounts.

Right.

> We might need a user_mount hook which is called once the core kernel code
> determines that it is a a valid unprivileged mount (although the sb_mount
> hook will already have been called, IIUC).

Does the order matter between core code's and the security module's
permission checks? If it does, the cleanest would be to just move the
core checks before the sb_mount hook, no?

Miklos

2008-03-19 21:36:38

by James Morris

[permalink] [raw]
Subject: Re: [patch 00/11] mount ownership and unprivileged mount syscall (v9)

On Tue, 18 Mar 2008, Miklos Szeredi wrote:

> > We might need a user_mount hook which is called once the core kernel code
> > determines that it is a a valid unprivileged mount (although the sb_mount
> > hook will already have been called, IIUC).
>
> Does the order matter between core code's and the security module's
> permission checks?

Yes, the model is DAC before MAC.

> If it does, the cleanest would be to just move the
> core checks before the sb_mount hook, no?

Correct.

--
James Morris
<[email protected]>