From: Roberts, W. C <wil...@in...> - 2015-07-13 23:58:16
|
Hello, In the normal flow of setting a fuse filesystem, one does: 1. Open /dev/fuse 2. Mount the filesystem passing the fd 3. Have a thread or threads reading requests off of /dev/fuse Is it possible to register device handles (ie wait reading on /dev/fuse) and then issuing the mount? (switch 2 and 3) so when the mount occurs the filesystem can handle getxattr calls. This stems from a long running issue with fuse and selinux and would be nice to perhaps finally correct this. Bill |
From: Stef B. <st...@gm...> - 2015-07-22 15:46:41
|
Hi, recently I've looking to this code. It's of course possible to add the fd to an eventloop before the mount. But are you sure there are getxattr calls -- before -- the mount? It looks a bit weird to me. Stef |
From: Roberts, W. C <wil...@in...> - 2015-07-22 16:24:17
|
> -----Original Message----- > From: Stef Bon [mailto:st...@gm...] > Sent: Wednesday, July 22, 2015 8:47 AM > To: Roberts, William C > Cc: fus...@li... > Subject: Re: [fuse-devel] setting up handlers before mount > > Hi, > > recently I've looking to this code. > > It's of course possible to add the fd to an eventloop before the mount. > But are you sure there are getxattr calls -- before -- the mount? > Is this currently supported by fuse and if so do you know if it was introduced In some particular kernel version? > It looks a bit weird to me. During the mount, SELinux (and likely other label based LSM's) need to query the label of the root node for its context. The Android sdcard is supported by a fusefs that enforces some permissions and checks, it does not use libfuse due to licensing issues (Google not me). I Attempted to have a handler waiting on /dev/fuse prior to the mount but was getting errors thrown on the read. |
From: Stef B. <st...@gm...> - 2015-07-22 16:38:30
|
2015-07-22 18:24 GMT+02:00 Roberts, William C <wil...@in...>: > > > > Is this currently supported by fuse and if so do you know if it was introduced > In some particular kernel version? No it's not supported yet. I'm working on my own library to interface with the kernel, so I know it's possible to do. When I say it's possible I mean it's technically possible to write. > >> It looks a bit weird to me. > > During the mount, SELinux (and likely other label based LSM's) need to query > the label of the root node for its context. The Android sdcard is supported by a > fusefs that enforces some permissions and checks, it does not use libfuse due > to licensing issues (Google not me). I Attempted to have a handler waiting on > /dev/fuse prior to the mount but was getting errors thrown on the read. > Now this is a chicken - egg problem. You cannot handle requests (getxattr calls for security. named xattr) when the filesystem is not yet mounted. You can - I mean here of course in theory - add the fd to an eventloop, attach a default handler to it, mount the fuse fs, and than replace/adjust the handler. Stef |
From: Roberts, W. C <wil...@in...> - 2015-07-22 17:54:44
|
> -----Original Message----- > From: Stef Bon [mailto:st...@gm...] > Sent: Wednesday, July 22, 2015 9:38 AM > To: Roberts, William C > Cc: fus...@li... > Subject: Re: [fuse-devel] setting up handlers before mount > > 2015-07-22 18:24 GMT+02:00 Roberts, William C <wil...@in...>: > > > > > > > > Is this currently supported by fuse and if so do you know if it was > > introduced In some particular kernel version? > > No it's not supported yet. > I'm working on my own library to interface with the kernel, so I know it's possible > to do. > When I say it's possible I mean it's technically possible to write. Android talks to fuse directly no libfuse. > > > > >> It looks a bit weird to me. > > > > During the mount, SELinux (and likely other label based LSM's) need to > > query the label of the root node for its context. The Android sdcard > > is supported by a fusefs that enforces some permissions and checks, it > > does not use libfuse due to licensing issues (Google not me). I > > Attempted to have a handler waiting on /dev/fuse prior to the mount but was > getting errors thrown on the read. > > > > Now this is a chicken - egg problem. You cannot handle requests (getxattr calls for > security. named xattr) when the filesystem is not yet mounted. It's during the mount I need to handle the getxattr call. So the mount is partially complete and the getxattr comes in. I *think* this happens in vfs above the actual call to the fs. But as you said, which becomes more apparent as I think about it, where would fuse send the request since the mapping between fd and file system hasn't been made by mount within fuse. Is this understanding correct? Currently SELinux has options like context= to specify the context to apply to a whole Filesystem but doesn’t have the ability to say, only use it for the mount context, perhaps that's a simpler approach. If we could specify to use xattr for the fs, but pass the mountcontext= option we could avoid this issue in fuse. The other option, just to pose the flipside, would be the way to have some mechanism to uniquely Identify a fuse filesystem mount prior to the mount. But this seems odd enough. > You can - I mean here of course in theory - add the fd to an eventloop, attach a > default handler to it, mount the fuse fs, and then replace/adjust the handler. > I had a loop sitting on read(fd, ...) with the same fd as what was being passed to mount and it seemed to come back with failures. Let me re-test, make sure I didn't to something dumb and collect some errors. |
From: Michael j T. <mt...@us...> - 2015-07-22 18:20:18
|
"Roberts, William C" <wil...@in...> wrote on 07/22/2015 12:54:23 PM: > From: "Roberts, William C" <wil...@in...> > To: Stef Bon <st...@gm...> > Cc: "fus...@li..." <fus...@li...> > Date: 07/22/2015 12:58 PM > Subject: Re: [fuse-devel] setting up handlers before mount > > > > > -----Original Message----- > > From: Stef Bon [mailto:st...@gm...] > > Sent: Wednesday, July 22, 2015 9:38 AM > > To: Roberts, William C > > Cc: fus...@li... > > Subject: Re: [fuse-devel] setting up handlers before mount > > > > 2015-07-22 18:24 GMT+02:00 Roberts, William C <wil...@in...>: > > > > > > > > > > > > Is this currently supported by fuse and if so do you know if it was > > > introduced In some particular kernel version? > > > > No it's not supported yet. > > I'm working on my own library to interface with the kernel, so I > know it's possible > > to do. > > When I say it's possible I mean it's technically possible to write. > > Android talks to fuse directly no libfuse. > > > > > > > > >> It looks a bit weird to me. > > > > > > During the mount, SELinux (and likely other label based LSM's) need to > > > query the label of the root node for its context. The Android sdcard > > > is supported by a fusefs that enforces some permissions and checks, it > > > does not use libfuse due to licensing issues (Google not me). I > > > Attempted to have a handler waiting on /dev/fuse prior to the > mount but was > > getting errors thrown on the read. > > > > > > > Now this is a chicken - egg problem. You cannot handle requests > (getxattr calls for > > security. named xattr) when the filesystem is not yet mounted. > > It's during the mount I need to handle the getxattr call. So the > mount is partially complete > and the getxattr comes in. I *think* this happens in vfs above the > actual call to the fs. > But as you said, which becomes more apparent as I think about it, > where would fuse send the > request since the mapping between fd and file system hasn't been > made by mount within > fuse. Is this understanding correct? > > Currently SELinux has options like context= to specify the context > to apply to a whole > Filesystem but doesn’t have the ability to say, only use it for the > mount context, perhaps that's > a simpler approach. If we could specify to use xattr for the fs, but > pass the mountcontext= option > we could avoid this issue in fuse. > Somewhat related to this, it would be really nice if fuse_mount() passed the context=, fscontext=, defcontext=, rootcontext= mount options down. > The other option, just to pose the flipside, would be the way to > have some mechanism to uniquely > Identify a fuse filesystem mount prior to the mount. But this seems > odd enough. > > > You can - I mean here of course in theory - add the fd to an > eventloop, attach a > > default handler to it, mount the fuse fs, and then replace/adjust > the handler. > > > > I had a loop sitting on read(fd, ...) with the same fd as what was > being passed to mount and it > seemed to come back with failures. Let me re-test, make sure I > didn't to something dumb and > collect some errors. > > > ------------------------------------------------------------------------------ > _______________________________________________ > fuse-devel mailing list > fus...@li... > https://lists.sourceforge.net/lists/listinfo/fuse-devel Regards, Michael Theall |
From: Roberts, W. C <wil...@in...> - 2015-07-22 22:05:16
|
From: Michael j Theall [mailto:mt...@us...] Sent: Wednesday, July 22, 2015 11:34 AM To: Roberts, William C Cc: fus...@li...; Stef Bon Subject: RE: [fuse-devel] setting up handlers before mount Regards, Michael Theall "Roberts, William C" <wil...@in...<mailto:wil...@in...>> wrote on 07/22/2015 01:23:00 PM: > From: "Roberts, William C" <wil...@in...<mailto:wil...@in...>> > To: Michael j Theall/Houston/IBM@IBMUS > Cc: "fus...@li...<mailto:fus...@li...>" <fuse- > de...@li...<mailto:de...@li...>>, Stef Bon <st...@gm...<mailto:st...@gm...>> > Date: 07/22/2015 01:23 PM > Subject: RE: [fuse-devel] setting up handlers before mount > > > > From: Michael j Theall [mailto:mt...@us...] > Sent: Wednesday, July 22, 2015 11:19 AM > To: Roberts, William C > Cc: fus...@li...<mailto:fus...@li...>; Stef Bon > Subject: Re: [fuse-devel] setting up handlers before mount > > "Roberts, William C" <wil...@in...<mailto:wil...@in...>> wrote on 07/22/ > 2015 12:54:23 PM: > > > From: "Roberts, William C" <wil...@in...<mailto:wil...@in...>> > > To: Stef Bon <st...@gm...<mailto:st...@gm...>> > > Cc: "fus...@li...<mailto:fus...@li...>" <fus...@li...<mailto:fus...@li...>> > > Date: 07/22/2015 12:58 PM > > Subject: Re: [fuse-devel] setting up handlers before mount > > > > > > > > > -----Original Message----- > > > From: Stef Bon [mailto:st...@gm...] > > > Sent: Wednesday, July 22, 2015 9:38 AM > > > To: Roberts, William C > > > Cc: fus...@li...<mailto:fus...@li...> > > > Subject: Re: [fuse-devel] setting up handlers before mount > > > > > > 2015-07-22 18:24 GMT+02:00 Roberts, William C <wil...@in... <mailto:wil...@in...%0b>> >: > > > > > > > > > > > > > > > > Is this currently supported by fuse and if so do you know if it was > > > > introduced In some particular kernel version? > > > > > > No it's not supported yet. > > > I'm working on my own library to interface with the kernel, so I > > know it's possible > > > to do. > > > When I say it's possible I mean it's technically possible to write. > > > > Android talks to fuse directly no libfuse. > > > > > > > > > > > > >> It looks a bit weird to me. > > > > > > > > During the mount, SELinux (and likely other label based LSM's) need to > > > > query the label of the root node for its context. The Android sdcard > > > > is supported by a fusefs that enforces some permissions and checks, it > > > > does not use libfuse due to licensing issues (Google not me). I > > > > Attempted to have a handler waiting on /dev/fuse prior to the > > mount but was > > > getting errors thrown on the read. > > > > > > > > > > Now this is a chicken - egg problem. You cannot handle requests > > (getxattr calls for > > > security. named xattr) when the filesystem is not yet mounted. > > > > It's during the mount I need to handle the getxattr call. So the > > mount is partially complete > > and the getxattr comes in. I *think* this happens in vfs above the > > actual call to the fs. > > But as you said, which becomes more apparent as I think about it, > > where would fuse send the > > request since the mapping between fd and file system hasn't been > > made by mount within > > fuse. Is this understanding correct? > > > > Currently SELinux has options like context= to specify the context > > to apply to a whole > > Filesystem but doesn’t have the ability to say, only use it for the > > mount context, perhaps that's > > a simpler approach. If we could specify to use xattr for the fs, but > > pass the mountcontext= option > > we could avoid this issue in fuse. > > > > Somewhat related to this, it would be really nice if fuse_mount() passed > the context=, fscontext=, defcontext=, rootcontext= mount options down. > It does, I know currently context= works on fuse. Not working for me. It fails in fuse_lowlevel_new() because it doesn't appear in fuse_ll_opts which causes fuse_opt_parse() to fail with: fuse: unknown option `context=system_u:object_r:removable_t' Ahh that sounds more like a libfuse issue sanitizing mount parameters or something. I can say if you call mount directly (no libfuse) it works. Additionally, that context looks wrong, you would need a :s0 (or the proper sensitivity and category combo) to mount on the end > > > The other option, just to pose the flipside, would be the way to > > have some mechanism to uniquely > > Identify a fuse filesystem mount prior to the mount. But this seems > > odd enough. > > > > > You can - I mean here of course in theory - add the fd to an > > eventloop, attach a > > > default handler to it, mount the fuse fs, and then replace/adjust > > the handler. > > > > > > > I had a loop sitting on read(fd, ...) with the same fd as what was > > being passed to mount and it > > seemed to come back with failures. Let me re-test, make sure I > > didn't to something dumb and > > collect some errors. > > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > fuse-devel mailing list > > fus...@li...<mailto:fus...@li...> > > https://lists.sourceforge.net/lists/listinfo/fuse-devel > > Regards, > Michael Theall |
From: Michael j T. <mt...@us...> - 2015-07-22 22:20:18
|
"Roberts, William C" <wil...@in...> wrote on 07/22/2015 05:05:05 PM: > From: "Roberts, William C" <wil...@in...> > To: Michael j Theall/Houston/IBM@IBMUS > Cc: "fus...@li..." <fuse- > de...@li...>, Stef Bon <st...@gm...> > Date: 07/22/2015 05:05 PM > Subject: RE: [fuse-devel] setting up handlers before mount > > > > From: Michael j Theall [mailto:mt...@us...] > Sent: Wednesday, July 22, 2015 11:34 AM > To: Roberts, William C > Cc: fus...@li...; Stef Bon > Subject: RE: [fuse-devel] setting up handlers before mount > > > > Regards, > Michael Theall > > "Roberts, William C" <wil...@in...> wrote on 07/22/ > 2015 01:23:00 PM: > > > From: "Roberts, William C" <wil...@in...> > > To: Michael j Theall/Houston/IBM@IBMUS > > Cc: "fus...@li..." <fuse- > > de...@li...>, Stef Bon <st...@gm...> > > Date: 07/22/2015 01:23 PM > > Subject: RE: [fuse-devel] setting up handlers before mount > > > > > > > > From: Michael j Theall [mailto:mt...@us...] > > Sent: Wednesday, July 22, 2015 11:19 AM > > To: Roberts, William C > > Cc: fus...@li...; Stef Bon > > Subject: Re: [fuse-devel] setting up handlers before mount > > > > "Roberts, William C" <wil...@in...> wrote on 07/22/ > > 2015 12:54:23 PM: > > > > > From: "Roberts, William C" <wil...@in...> > > > To: Stef Bon <st...@gm...> > > > Cc: "fus...@li..." <fus...@li...> > > > Date: 07/22/2015 12:58 PM > > > Subject: Re: [fuse-devel] setting up handlers before mount > > > > > > > > > > > > > -----Original Message----- > > > > From: Stef Bon [mailto:st...@gm...] > > > > Sent: Wednesday, July 22, 2015 9:38 AM > > > > To: Roberts, William C > > > > Cc: fus...@li... > > > > Subject: Re: [fuse-devel] setting up handlers before mount > > > > > > > > 2015-07-22 18:24 GMT+02:00 Roberts, William C < > wil...@in... > > >: > > > > > > > > > > > > > > > > > > > > Is this currently supported by fuse and if so do you know if it was > > > > > introduced In some particular kernel version? > > > > > > > > No it's not supported yet. > > > > I'm working on my own library to interface with the kernel, so I > > > know it's possible > > > > to do. > > > > When I say it's possible I mean it's technically possible to write. > > > > > > Android talks to fuse directly no libfuse. > > > > > > > > > > > > > > > > >> It looks a bit weird to me. > > > > > > > > > > During the mount, SELinux (and likely other label based LSM's) need to > > > > > query the label of the root node for its context. The Android sdcard > > > > > is supported by a fusefs that enforces some permissions and checks, it > > > > > does not use libfuse due to licensing issues (Google not me). I > > > > > Attempted to have a handler waiting on /dev/fuse prior to the > > > mount but was > > > > getting errors thrown on the read. > > > > > > > > > > > > > Now this is a chicken - egg problem. You cannot handle requests > > > (getxattr calls for > > > > security. named xattr) when the filesystem is not yet mounted. > > > > > > It's during the mount I need to handle the getxattr call. So the > > > mount is partially complete > > > and the getxattr comes in. I *think* this happens in vfs above the > > > actual call to the fs. > > > But as you said, which becomes more apparent as I think about it, > > > where would fuse send the > > > request since the mapping between fd and file system hasn't been > > > made by mount within > > > fuse. Is this understanding correct? > > > > > > Currently SELinux has options like context= to specify the context > > > to apply to a whole > > > Filesystem but doesn’t have the ability to say, only use it for the > > > mount context, perhaps that's > > > a simpler approach. If we could specify to use xattr for the fs, but > > > pass the mountcontext= option > > > we could avoid this issue in fuse. > > > > > > > Somewhat related to this, it would be really nice if fuse_mount() passed > > the context=, fscontext=, defcontext=, rootcontext= mount options down. > > It does, I know currently context= works on fuse. > > Not working for me. It fails in fuse_lowlevel_new() because it doesn't > appear in fuse_ll_opts which causes fuse_opt_parse() to fail with: > fuse: unknown option `context=system_u:object_r:removable_t' > Ahh that sounds more like a libfuse issue sanitizing mount > parameters or something. I can say if you > call mount directly (no libfuse) it works. Additionally, > that context looks wrong, you would need a :s0 (or the proper > sensitivity and category combo) to mount > on the end > Yeah so what I learned is that it is added to libfuse 3.0 and works there (with the :s0 of course). So looks like I just need to wait for that to be released. My filesystem already supports xattrs so it would be great to get SELinux working fully in FUSE. I can live with using rootcontext= option if that prevents the current deadlock thing that everyone is talking about. > > > > > > The other option, just to pose the flipside, would be the way to > > > have some mechanism to uniquely > > > Identify a fuse filesystem mount prior to the mount. But this seems > > > odd enough. > > > > > > > You can - I mean here of course in theory - add the fd to an > > > eventloop, attach a > > > > default handler to it, mount the fuse fs, and then replace/adjust > > > the handler. > > > > > > > > > > I had a loop sitting on read(fd, ...) with the same fd as what was > > > being passed to mount and it > > > seemed to come back with failures. Let me re-test, make sure I > > > didn't to something dumb and > > > collect some errors. > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > > > fuse-devel mailing list > > > fus...@li... > > > https://lists.sourceforge.net/lists/listinfo/fuse-devel > > > > Regards, > > Michael Theall |
From: Roberts, W. C <wil...@in...> - 2015-07-22 22:17:14
|
From: Michael j Theall [mailto:mt...@us...] Sent: Wednesday, July 22, 2015 3:09 PM To: Roberts, William C Cc: fus...@li...; Stef Bon Subject: RE: [fuse-devel] setting up handlers before mount "Roberts, William C" <wil...@in...<mailto:wil...@in...>> wrote on 07/22/2015 05:05:05 PM: > From: "Roberts, William C" <wil...@in...<mailto:wil...@in...>> > To: Michael j Theall/Houston/IBM@IBMUS > Cc: "fus...@li...<mailto:fus...@li...>" <fuse- > de...@li...<mailto:de...@li...>>, Stef Bon <st...@gm...<mailto:st...@gm...>> > Date: 07/22/2015 05:05 PM > Subject: RE: [fuse-devel] setting up handlers before mount > > > > From: Michael j Theall [mailto:mt...@us...] > Sent: Wednesday, July 22, 2015 11:34 AM > To: Roberts, William C > Cc: fus...@li...<mailto:fus...@li...>; Stef Bon > Subject: RE: [fuse-devel] setting up handlers before mount > > > > Regards, > Michael Theall > > "Roberts, William C" <wil...@in...<mailto:wil...@in...>> wrote on 07/22/ > 2015 01:23:00 PM: > > > From: "Roberts, William C" <wil...@in...<mailto:wil...@in...>> > > To: Michael j Theall/Houston/IBM@IBMUS > > Cc: "fus...@li...<mailto:fus...@li...>" <fuse- > > de...@li...<mailto:de...@li...>>, Stef Bon <st...@gm...<mailto:st...@gm...>> > > Date: 07/22/2015 01:23 PM > > Subject: RE: [fuse-devel] setting up handlers before mount > > > > > > > > From: Michael j Theall [mailto:mt...@us...] > > Sent: Wednesday, July 22, 2015 11:19 AM > > To: Roberts, William C > > Cc: fus...@li...<mailto:fus...@li...>; Stef Bon > > Subject: Re: [fuse-devel] setting up handlers before mount > > > > "Roberts, William C" <wil...@in...<mailto:wil...@in...>> wrote on 07/22/ > > 2015 12:54:23 PM: > > > > > From: "Roberts, William C" <wil...@in...<mailto:wil...@in...>> > > > To: Stef Bon <st...@gm...<mailto:st...@gm...>> > > > Cc: "fus...@li...<mailto:fus...@li...>" <fus...@li...<mailto:fus...@li...>> > > > Date: 07/22/2015 12:58 PM > > > Subject: Re: [fuse-devel] setting up handlers before mount > > > > > > > > > > > > > -----Original Message----- > > > > From: Stef Bon [mailto:st...@gm...] > > > > Sent: Wednesday, July 22, 2015 9:38 AM > > > > To: Roberts, William C > > > > Cc: fus...@li...<mailto:fus...@li...> > > > > Subject: Re: [fuse-devel] setting up handlers before mount > > > > > > > > 2015-07-22 18:24 GMT+02:00 Roberts, William C < > wil...@in...<mailto:wil...@in...> > > >: > > > > > > > > > > > > > > > > > > > > Is this currently supported by fuse and if so do you know if it was > > > > > introduced In some particular kernel version? > > > > > > > > No it's not supported yet. > > > > I'm working on my own library to interface with the kernel, so I > > > know it's possible > > > > to do. > > > > When I say it's possible I mean it's technically possible to write. > > > > > > Android talks to fuse directly no libfuse. > > > > > > > > > > > > > > > > >> It looks a bit weird to me. > > > > > > > > > > During the mount, SELinux (and likely other label based LSM's) need to > > > > > query the label of the root node for its context. The Android sdcard > > > > > is supported by a fusefs that enforces some permissions and checks, it > > > > > does not use libfuse due to licensing issues (Google not me). I > > > > > Attempted to have a handler waiting on /dev/fuse prior to the > > > mount but was > > > > getting errors thrown on the read. > > > > > > > > > > > > > Now this is a chicken - egg problem. You cannot handle requests > > > (getxattr calls for > > > > security. named xattr) when the filesystem is not yet mounted. > > > > > > It's during the mount I need to handle the getxattr call. So the > > > mount is partially complete > > > and the getxattr comes in. I *think* this happens in vfs above the > > > actual call to the fs. > > > But as you said, which becomes more apparent as I think about it, > > > where would fuse send the > > > request since the mapping between fd and file system hasn't been > > > made by mount within > > > fuse. Is this understanding correct? > > > > > > Currently SELinux has options like context= to specify the context > > > to apply to a whole > > > Filesystem but doesn’t have the ability to say, only use it for the > > > mount context, perhaps that's > > > a simpler approach. If we could specify to use xattr for the fs, but > > > pass the mountcontext= option > > > we could avoid this issue in fuse. > > > > > > > Somewhat related to this, it would be really nice if fuse_mount() passed > > the context=, fscontext=, defcontext=, rootcontext= mount options down. > > It does, I know currently context= works on fuse. > > Not working for me. It fails in fuse_lowlevel_new() because it doesn't > appear in fuse_ll_opts which causes fuse_opt_parse() to fail with: > fuse: unknown option `context=system_u:object_r:removable_t' > Ahh that sounds more like a libfuse issue sanitizing mount > parameters or something. I can say if you > call mount directly (no libfuse) it works. Additionally, > that context looks wrong, you would need a :s0 (or the proper > sensitivity and category combo) to mount > on the end > Yeah so what I learned is that it is added to libfuse 3.0 and works there (with the :s0 of course). So looks like I just need to wait for that to be released. My filesystem already supports xattrs so it would be great to get SELinux working fully in FUSE. I can live with using rootcontext= option if that prevents the current deadlock thing that everyone is talking about. Unfortunately it does not at this moment. I asked this same question on the SELinux list and I quote from Stephen Smalley, “rootcontext= is typically used to assign a specific context to the root directory of e.g. tmpfs mounts, rather than having to first mount it and then change the context to some value. Using it wouldn't suppress the getxattr call by SELinux for a fs_use_xattr filesystem, as SELinux always does that regardless just to probe whether the filesystem supports security xattrs (if not, then it will fail the mount). It would however override any underlying xattr value for the root directory.” http://marc.info/?l=selinux&m=143691597530832&w=2 Also you need to add an fs_use statement for fuse to use xattr’s. So even if we correct this, it will still cause an issue with other fusefs that do not support it. > > > > > > The other option, just to pose the flipside, would be the way to > > > have some mechanism to uniquely > > > Identify a fuse filesystem mount prior to the mount. But this seems > > > odd enough. > > > > > > > You can - I mean here of course in theory - add the fd to an > > > eventloop, attach a > > > > default handler to it, mount the fuse fs, and then replace/adjust > > > the handler. > > > > > > > > > > I had a loop sitting on read(fd, ...) with the same fd as what was > > > being passed to mount and it > > > seemed to come back with failures. Let me re-test, make sure I > > > didn't to something dumb and > > > collect some errors. > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > > > fuse-devel mailing list > > > fus...@li...<mailto:fus...@li...> > > > https://lists.sourceforge.net/lists/listinfo/fuse-devel > > > > Regards, > > Michael Theall |
From: Roberts, W. C <wil...@in...> - 2015-07-22 18:23:09
|
From: Michael j Theall [mailto:mt...@us...] Sent: Wednesday, July 22, 2015 11:19 AM To: Roberts, William C Cc: fus...@li...; Stef Bon Subject: Re: [fuse-devel] setting up handlers before mount "Roberts, William C" <wil...@in...<mailto:wil...@in...>> wrote on 07/22/2015 12:54:23 PM: > From: "Roberts, William C" <wil...@in...<mailto:wil...@in...>> > To: Stef Bon <st...@gm...<mailto:st...@gm...>> > Cc: "fus...@li...<mailto:fus...@li...>" <fus...@li...<mailto:fus...@li...>> > Date: 07/22/2015 12:58 PM > Subject: Re: [fuse-devel] setting up handlers before mount > > > > > -----Original Message----- > > From: Stef Bon [mailto:st...@gm...] > > Sent: Wednesday, July 22, 2015 9:38 AM > > To: Roberts, William C > > Cc: fus...@li...<mailto:fus...@li...> > > Subject: Re: [fuse-devel] setting up handlers before mount > > > > 2015-07-22 18:24 GMT+02:00 Roberts, William C <wil...@in...<mailto:wil...@in...>>: > > > > > > > > > > > > Is this currently supported by fuse and if so do you know if it was > > > introduced In some particular kernel version? > > > > No it's not supported yet. > > I'm working on my own library to interface with the kernel, so I > know it's possible > > to do. > > When I say it's possible I mean it's technically possible to write. > > Android talks to fuse directly no libfuse. > > > > > > > > >> It looks a bit weird to me. > > > > > > During the mount, SELinux (and likely other label based LSM's) need to > > > query the label of the root node for its context. The Android sdcard > > > is supported by a fusefs that enforces some permissions and checks, it > > > does not use libfuse due to licensing issues (Google not me). I > > > Attempted to have a handler waiting on /dev/fuse prior to the > mount but was > > getting errors thrown on the read. > > > > > > > Now this is a chicken - egg problem. You cannot handle requests > (getxattr calls for > > security. named xattr) when the filesystem is not yet mounted. > > It's during the mount I need to handle the getxattr call. So the > mount is partially complete > and the getxattr comes in. I *think* this happens in vfs above the > actual call to the fs. > But as you said, which becomes more apparent as I think about it, > where would fuse send the > request since the mapping between fd and file system hasn't been > made by mount within > fuse. Is this understanding correct? > > Currently SELinux has options like context= to specify the context > to apply to a whole > Filesystem but doesn’t have the ability to say, only use it for the > mount context, perhaps that's > a simpler approach. If we could specify to use xattr for the fs, but > pass the mountcontext= option > we could avoid this issue in fuse. > Somewhat related to this, it would be really nice if fuse_mount() passed the context=, fscontext=, defcontext=, rootcontext= mount options down. It does, I know currently context= works on fuse. > The other option, just to pose the flipside, would be the way to > have some mechanism to uniquely > Identify a fuse filesystem mount prior to the mount. But this seems > odd enough. > > > You can - I mean here of course in theory - add the fd to an > eventloop, attach a > > default handler to it, mount the fuse fs, and then replace/adjust > the handler. > > > > I had a loop sitting on read(fd, ...) with the same fd as what was > being passed to mount and it > seemed to come back with failures. Let me re-test, make sure I > didn't to something dumb and > collect some errors. > > > ------------------------------------------------------------------------------ > _______________________________________________ > fuse-devel mailing list > fus...@li...<mailto:fus...@li...> > https://lists.sourceforge.net/lists/listinfo/fuse-devel Regards, Michael Theall |
From: Michael j T. <mt...@us...> - 2015-07-22 18:35:14
|
Regards, Michael Theall "Roberts, William C" <wil...@in...> wrote on 07/22/2015 01:23:00 PM: > From: "Roberts, William C" <wil...@in...> > To: Michael j Theall/Houston/IBM@IBMUS > Cc: "fus...@li..." <fuse- > de...@li...>, Stef Bon <st...@gm...> > Date: 07/22/2015 01:23 PM > Subject: RE: [fuse-devel] setting up handlers before mount > > > > From: Michael j Theall [mailto:mt...@us...] > Sent: Wednesday, July 22, 2015 11:19 AM > To: Roberts, William C > Cc: fus...@li...; Stef Bon > Subject: Re: [fuse-devel] setting up handlers before mount > > "Roberts, William C" <wil...@in...> wrote on 07/22/ > 2015 12:54:23 PM: > > > From: "Roberts, William C" <wil...@in...> > > To: Stef Bon <st...@gm...> > > Cc: "fus...@li..." <fus...@li...> > > Date: 07/22/2015 12:58 PM > > Subject: Re: [fuse-devel] setting up handlers before mount > > > > > > > > > -----Original Message----- > > > From: Stef Bon [mailto:st...@gm...] > > > Sent: Wednesday, July 22, 2015 9:38 AM > > > To: Roberts, William C > > > Cc: fus...@li... > > > Subject: Re: [fuse-devel] setting up handlers before mount > > > > > > 2015-07-22 18:24 GMT+02:00 Roberts, William C <wil...@in... > >: > > > > > > > > > > > > > > > > Is this currently supported by fuse and if so do you know if it was > > > > introduced In some particular kernel version? > > > > > > No it's not supported yet. > > > I'm working on my own library to interface with the kernel, so I > > know it's possible > > > to do. > > > When I say it's possible I mean it's technically possible to write. > > > > Android talks to fuse directly no libfuse. > > > > > > > > > > > > >> It looks a bit weird to me. > > > > > > > > During the mount, SELinux (and likely other label based LSM's) need to > > > > query the label of the root node for its context. The Android sdcard > > > > is supported by a fusefs that enforces some permissions and checks, it > > > > does not use libfuse due to licensing issues (Google not me). I > > > > Attempted to have a handler waiting on /dev/fuse prior to the > > mount but was > > > getting errors thrown on the read. > > > > > > > > > > Now this is a chicken - egg problem. You cannot handle requests > > (getxattr calls for > > > security. named xattr) when the filesystem is not yet mounted. > > > > It's during the mount I need to handle the getxattr call. So the > > mount is partially complete > > and the getxattr comes in. I *think* this happens in vfs above the > > actual call to the fs. > > But as you said, which becomes more apparent as I think about it, > > where would fuse send the > > request since the mapping between fd and file system hasn't been > > made by mount within > > fuse. Is this understanding correct? > > > > Currently SELinux has options like context= to specify the context > > to apply to a whole > > Filesystem but doesn’t have the ability to say, only use it for the > > mount context, perhaps that's > > a simpler approach. If we could specify to use xattr for the fs, but > > pass the mountcontext= option > > we could avoid this issue in fuse. > > > > Somewhat related to this, it would be really nice if fuse_mount() passed > the context=, fscontext=, defcontext=, rootcontext= mount options down. > It does, I know currently context= works on fuse. Not working for me. It fails in fuse_lowlevel_new() because it doesn't appear in fuse_ll_opts which causes fuse_opt_parse() to fail with: fuse: unknown option `context=system_u:object_r:removable_t' > > > The other option, just to pose the flipside, would be the way to > > have some mechanism to uniquely > > Identify a fuse filesystem mount prior to the mount. But this seems > > odd enough. > > > > > You can - I mean here of course in theory - add the fd to an > > eventloop, attach a > > > default handler to it, mount the fuse fs, and then replace/adjust > > the handler. > > > > > > > I had a loop sitting on read(fd, ...) with the same fd as what was > > being passed to mount and it > > seemed to come back with failures. Let me re-test, make sure I > > didn't to something dumb and > > collect some errors. > > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > fuse-devel mailing list > > fus...@li... > > https://lists.sourceforge.net/lists/listinfo/fuse-devel > > Regards, > Michael Theall |
From: Stef B. <st...@gm...> - 2015-07-22 19:57:06
|
Hi, >> When I say it's possible I mean it's technically possible to write. >Android talks to fuse directly no libfuse. Ok I understand Android has -- no libfuse -- but has fuse (== kernel interface to userspace). Your remark "Android talks to fuse directly" makes no sense! Don't make it more difficult. There must be a library or code linked in the userspace filesystem which creates the fd, mounts and creates an eventloop. It's better to discuss here what this code is, and this problem occurs only with this filesystem, or with all kinds of userspace filesystems for Android. Stef |
From: Roberts, W. C <wil...@in...> - 2015-07-22 22:09:31
|
> -----Original Message----- > From: Stef Bon [mailto:st...@gm...] > Sent: Wednesday, July 22, 2015 12:57 PM > To: Roberts, William C > Cc: Michael j Theall; fus...@li... > Subject: Re: [fuse-devel] setting up handlers before mount > > Hi, > > >> When I say it's possible I mean it's technically possible to write. > > >Android talks to fuse directly no libfuse. > > Ok I understand Android has -- no libfuse -- but has fuse (== kernel interface to > userspace). > > Your remark "Android talks to fuse directly" makes no sense! Don't make it more > difficult. > > There must be a library or code linked in the userspace filesystem which creates > the fd, mounts and creates an eventloop. > It's better to discuss here what this code is, and this problem occurs only with this > filesystem, or with all kinds of userspace filesystems for Android. What do you mean it makes no sense? Perhaps I am explaining poorly. It doesn't use any helper libraries, only the kernel uapi headers and libc. When we need an fd off of /dev/fuse, we open it ourselves, when we need to mount, we call mount ourselves, when we need an event loop, we code it ourselves (I use ourselves loosely to mean Android). Take a look at the sdcard.c file following the entry point at main. https://android.googlesource.com/platform/system/core/+/master/sdcard/sdcard.c |
From: Stef B. <st...@gm...> - 2015-07-23 07:36:55
|
2015-07-23 0:09 GMT+02:00 Roberts, William C <wil...@in...>: > > >> -----Original Message----- >> From: Stef Bon [mailto:st...@gm...] >> Your remark "Android talks to fuse directly" makes no sense! Don't make it more >> difficult. >> >> There must be a library or code linked in the userspace filesystem which creates >> the fd, mounts and creates an eventloop. >> It's better to discuss here what this code is, and this problem occurs only with this >> filesystem, or with all kinds of userspace filesystems for Android. > > What do you mean it makes no sense? Perhaps I am explaining poorly. It doesn't use any helper libraries, > only the kernel uapi headers and libc. When we need an fd off of /dev/fuse, we open it ourselves, when > we need to mount, we call mount ourselves, when we need an event loop, we code it > ourselves (I use ourselves loosely to mean Android). > > Take a look at the sdcard.c file following the entry point at main. > https://android.googlesource.com/platform/system/core/+/master/sdcard/sdcard.c You say that Android talks to fuse directly. Now FUSE is the kernel module, enabling userspace mounts, and the kernel is always talking to a kernel module directly. You mean you cannot use the fuse library. Now what I see from the code is to play with the order. Add the fd first to the eventloop, and then mount. See what happens, and see what requests are coming from the kernel. As I understand that these are SE related. Stef |