From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757701AbbEVRh2 (ORCPT ); Fri, 22 May 2015 13:37:28 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:41738 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750757AbbEVRhZ (ORCPT ); Fri, 22 May 2015 13:37:25 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Miklos Szeredi Cc: alexey@kurnosov.spb.ru, Seth Forshee , Andy Lutomirski , Serge Hallyn , fuse-devel , Linux-Fsdevel , Kernel Mailing List References: <20150331011423.GC13083@unsen.q53.spb.ru> <20150401155515.GA2994@unsen.q53.spb.ru> <20150502155623.GD13083@unsen.q53.spb.ru> Date: Fri, 22 May 2015 12:32:18 -0500 In-Reply-To: (Miklos Szeredi's message of "Fri, 22 May 2015 16:23:55 +0200") Message-ID: <87k2w05xi5.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-AID: U2FsdGVkX1+A88SRM9CrlfpemS2l8bDKH2I7jbwyq8c= X-SA-Exim-Connect-IP: 67.3.205.90 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa07 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_03 6+ unique symbols in subject * 0.0 T_TooManySym_02 5+ unique symbols in subject * 0.0 T_TooManySym_01 4+ unique symbols in subject X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Miklos Szeredi X-Spam-Relay-Country: X-Spam-Timing: total 791 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 6 (0.8%), b_tie_ro: 3.9 (0.5%), parse: 0.70 (0.1%), extract_message_metadata: 20 (2.5%), get_uri_detail_list: 2.5 (0.3%), tests_pri_-1000: 11 (1.3%), tests_pri_-950: 1.34 (0.2%), tests_pri_-900: 1.10 (0.1%), tests_pri_-400: 34 (4.3%), check_bayes: 33 (4.1%), b_tokenize: 7 (0.9%), b_tok_get_all: 14 (1.7%), b_comp_prob: 2.7 (0.3%), b_tok_touch_all: 5 (0.7%), b_finish: 2.1 (0.3%), tests_pri_0: 665 (84.1%), tests_pri_500: 49 (6.2%), rewrite_mail: 0.00 (0.0%) Subject: Re: [fuse-devel] fuse_get_context() and namespaces X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Miklos Szeredi writes: > On Sat, May 2, 2015 at 5:56 PM, 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@sl7test ~]# lxc-start -n test-2 /bin/su - >> [root@test-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@test-2 ~]# python hello.py -f /mnt/ >> >> On second console: >> [root@test-2 ~]# echo $$ >> 41 >> [root@test-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