On Wed, Jan 17, 2018 at 11:59:06AM +0100, Alban Crequy wrote: > [Adding Tejun, David, Tom for question about cuse] > > On Fri, Dec 22, 2017 at 3:32 PM, Dongsu Park <dongsu@xxxxxxxxxx> wrote: > > From: Seth Forshee <seth.forshee@xxxxxxxxxxxxx> > > > > In order to support mounts from namespaces other than > > init_user_ns, fuse must translate uids and gids to/from the > > userns of the process servicing requests on /dev/fuse. This > > patch does that, with a couple of restrictions on the namespace: > > > > - The userns for the fuse connection is fixed to the namespace > > from which /dev/fuse is opened. > > > > - The namespace must be the same as s_user_ns. > > > > These restrictions simplify the implementation by avoiding the > > need to pass around userns references and by allowing fuse to > > rely on the checks in inode_change_ok for ownership changes. > > Either restriction could be relaxed in the future if needed. > > > > For cuse the namespace used for the connection is also simply > > current_user_ns() at the time /dev/cuse is opened. > > Was a use case discussed for using cuse in a new unprivileged userns? > > I ran some tests yesterday with cusexmp [1] and I could add a new char > device as an unprivileged user with: > > $ unshare -U -r -m sh -c 'mount --bind /mnt/cuse /dev/cuse ; cusexmp > --maj=99 --min=30 --name=foo > > where /mnt/cuse is previously mknod'ed correctly and chmod'ed 777. > Then, I could see the new device: > > $ cat /proc/devices | grep foo > 99 foo > > On normal distros, we don't have a /mnt/cuse chmod'ed 777 but still it > seems dangerous if the dev node can be provided otherwise and if we > don't have a use case for it. > > Thoughts? I can't remember the specific reasons, but I had concluded that letting unprivileged users use cuse within a user namespace isn't safe. But having a cuse device node usable by regular users at all is equally unsafe I suspect, so I don't think your example demonstrates any problem specific to user namespaces. There shouldn't be any way to use a user namespace to gain access permissions towards /dev/cuse, otherwise we have bigger problems than cuse to worry about. Seth
