linux-kernel - Re: [fuse-devel] fuse_get

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87k2w05xi5.fsf@x220.int.ebiederm.org>
Date:	Fri, 22 May 2015 12:32:18 -0500
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	alexey@...nosov.spb.ru, Seth Forshee <seth.forshee@...onical.com>,
	Andy Lutomirski <luto@...capital.net>,
	Serge Hallyn <serge.hallyn@...ntu.com>,
	fuse-devel <fuse-devel@...ts.sourceforge.net>,
	Linux-Fsdevel <linux-fsdevel@...r.kernel.org>,
	Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [fuse-devel] fuse_get_context() and namespaces

Miklos Szeredi <miklos@...redi.hu> writes:

> On Sat, May 2, 2015 at 5:56 PM,  <alexey@...nosov.spb.ru> wrote:
>>
>> 3.10.0-229 form Scientific Linux and native 4.0.1-1 (from elrepo).
>> SL 7.1 on the host and SL 6.6 on the LXC guest. At least in 3.10
>> the 499dcf2024092e5cce41d05599a5b51d1f92031a is present.
>> Steps to reproduce:
>>
>> On first console:
>> [root@...test ~]# lxc-start  -n test-2 /bin/su -
>> [root@...t-2 ~]# diff -u  hello.py /usr/share/doc/fuse-python-0.2.1/example/hello.py
>> --- hello.py    2015-05-02 11:12:13.963093580 -0400
>> +++ /usr/share/doc/fuse-python-0.2.1/example/hello.py   2010-04-14 18:29:21.000000000 -0400
>> @@ -41,8 +41,6 @@
>>  class HelloFS(Fuse):
>>
>>      def getattr(self, path):
>> -        dic = Fuse.GetContext(self)
>> -        print dic
>>          st = MyStat()
>>          if path == '/':
>>              st.st_mode = stat.S_IFDIR | 0755
>> [root@...t-2 ~]# python hello.py -f  /mnt/
>>
>> On second console:
>> [root@...t-2 ~]# echo $$
>> 41
>> [root@...t-2 ~]# ls /mnt/
>> hello
>>
>> Output of first console:
>> {'gid': 0, 'pid': 12083, 'uid': 0}
>
> Thanks.
>
> Digging in mailbox...  There was a thread last year about adding
> support for running fuse daemon in a container:
>
>   http://thread.gmane.org/gmane.linux.kernel/1811658
>
> Not sure what happened, but no updated patches have been posted or
> maybe I just missed them.

We had a discussion and decided to sort out and move as much
functionality as possible into the VFS before proceeding with fuse.
That way there are less weird corner cases to deal with in the review of
the fuse changes.

> Anyway... adding parties of that discussion to the Cc.

It is taking me a bit of work to have enough context to understand the
concern.

It seems user namespaces and unprivileged mounts are not in play which
is what Seth and I were primariliy focusing on.  So we do not have the
tricky privilege checks.

Looking at the reproducer above it appears that the issue is mounting a
fuse filesystem with global root permissions in a pid namespace.

The semantically correct behavior is to return pids to the fuse
filesystem that are in the namespace of the mounter of the fuse
filesystem, and clearly we are not doing that currently.

There are good ways and bad ways of doing that, the good ways don't
involve taking refcounts on struct pid.    I will take a look shortly
and review Seth's patch and see how well it does.  With a little luck
this should be a non-controversial fix.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/