Eric Haszlakiewicz wrote:
> I know approximately nothing about the FUSE protocol, but would it to be
> feasible to keep a fixed length header with a flag that says extra groups
> can be found in the payload of the message, either before or after the regular
> payload?
We could have a secondary g
On Wed, Dec 14, 2011 at 03:22:19PM -0600, Eric Haszlakiewicz wrote:
> On Wed, Dec 14, 2011 at 07:57:43AM +, Michael van Elst wrote:
> > mm_li...@pulsar-zone.net (Matthew Mondor) writes:
> >
> > >What does NFS do in this case? I seem to remember that it also imposes
> > >a sane size limit, pos
On Wed, Dec 14, 2011 at 07:57:43AM +, Michael van Elst wrote:
> mm_li...@pulsar-zone.net (Matthew Mondor) writes:
>
> >What does NFS do in this case? I seem to remember that it also imposes
> >a sane size limit, possibly even below NGROUPS_MAX, is it really the
> >case? If so, would this als
On Wed, Dec 14, 2011 at 07:04:06AM +0100, Emmanuel Dreyfus wrote:
> I explored the option of modifying the FUSE protocol, and that is
> though. We can easily negociate an extended FUSE header that contains
> secondary groups, and I already submitted a patch that does exactly
> that, but then we fac
On Dec 14, 6:05am, m...@netbsd.org (Emmanuel Dreyfus) wrote:
-- Subject: Re: [RFC] getgroups2 system call
| Christos Zoulas wrote:
|
| > Don't you need a getuid2(pid_t pid)?
|
| uid, gid and pid are passed inthe FUSE header, so we aready have them.
|
| > Why don't you a
On Wed, Dec 14, 2011 at 02:00:49PM +, Emmanuel Dreyfus wrote:
> On Wed, Dec 14, 2011 at 08:55:35AM -0500, Thor Lancelot Simon wrote:
> > So, um, whoever "considers" it that way -- they understand there are
> > security impliations to not doing it some other way?
>
> Not quite. But BTW, what ar
On Wed, Dec 14, 2011 at 08:55:35AM -0500, Thor Lancelot Simon wrote:
> So, um, whoever "considers" it that way -- they understand there are
> security impliations to not doing it some other way?
Not quite. But BTW, what are the security implication? The only case
I can think of is a thread doing a
On Wed, Dec 14, 2011 at 07:04:06AM +0100, Emmanuel Dreyfus wrote:
>
> desired. That last proposal has been considered "a series of hacks to
> make it confirm to the requirements", therefore I am left with fetching
> secondary groups asynchrnously through sysctl.
So, um, whoever "considers" it tha
David Holland wrote:
> So they want to do it right, but this causes trouble on Linux? Why is
> this *our* problem?
Our problem is to have NetBSD supporting FUSE filesystem, and this
sometime require changes to libfuse.
> Also, has fuse really been around this long without ever having had
> sup
On Wed, Dec 14, 2011 at 10:51:20AM +, Emmanuel Dreyfus wrote:
> On Wed, Dec 14, 2011 at 09:09:59AM +, YAMAMOTO Takashi wrote:
> > in my understanding, fuse_getgroups needs to talk with perfused,
> > not kernel. so i suggested creating a side channel between
> > fuse_getgroups and perfu
On Wed, Dec 14, 2011 at 08:19:42AM +, Emmanuel Dreyfus wrote:
> On Wed, Dec 14, 2011 at 01:10:19AM -0500, Matthew Mondor wrote:
> > What does NFS do in this case? I seem to remember that it also imposes
> > a sane size limit, possibly even below NGROUPS_MAX, is it really the
> > case? If
On Wed, Dec 14, 2011 at 09:09:59AM +, YAMAMOTO Takashi wrote:
> in my understanding, fuse_getgroups needs to talk with perfused, not kernel.
> so i suggested creating a side channel between fuse_getgroups and perfused.
There is a proposal from fuse-devel mailing list to add FUSE message to
sen
hi,
> On Wed, Dec 14, 2011 at 07:45:11AM +, YAMAMOTO Takashi wrote:
>> do you mean to implement fuse_getgroups for NetBSD with the sysctl?
>> if you are adding a #ifdef NetBSD block to the fuse, can't it use
>> a NetBSD-specific sidechannel to get the info from an appropriate
>> puffs-supplied
On Wed, Dec 14, 2011 at 07:45:11AM +, YAMAMOTO Takashi wrote:
> do you mean to implement fuse_getgroups for NetBSD with the sysctl?
> if you are adding a #ifdef NetBSD block to the fuse, can't it use
> a NetBSD-specific sidechannel to get the info from an appropriate
> puffs-supplied uucred?
F
On Wed, Dec 14, 2011 at 01:10:19AM -0500, Matthew Mondor wrote:
> What does NFS do in this case? I seem to remember that it also imposes
> a sane size limit, possibly even below NGROUPS_MAX, is it really the
> case? If so, would this also be acceptable?
FUSE people want the filesystem to accept
mm_li...@pulsar-zone.net (Matthew Mondor) writes:
>What does NFS do in this case? I seem to remember that it also imposes
>a sane size limit, possibly even below NGROUPS_MAX, is it really the
>case? If so, would this also be acceptable?
NFS (or rather the underlying SunRPC) passes an array of 1
hi,
> At this point, I think I will fetch secondary groups through sysctl,
> this seems to be the point of least resistance.
do you mean to implement fuse_getgroups for NetBSD with the sysctl?
if you are adding a #ifdef NetBSD block to the fuse, can't it use
a NetBSD-specific sidechannel to get t
On Wed, 14 Dec 2011 07:04:06 +0100
m...@netbsd.org (Emmanuel Dreyfus) wrote:
> - a fixed lentgh header is highly desirable for performance
> optimization. For instance glusterfs fetches the header and the data
> using readv(2) with an iovec that has two slots. That way it gets write
> date aligned
Thor Lancelot Simon wrote:
> > At this point, I think I will fetch secondary groups through sysctl,
> > this seems to be the point of least resistance.
>
> You are not worried about security issues resulting from the fact
> that time will pass, and the process may do other operations which
> mod
On Wed, Dec 14, 2011 at 06:05:53AM +0100, Emmanuel Dreyfus wrote:
>
> At this point, I think I will fetch secondary groups through sysctl,
> this seems to be the point of least resistance.
You are not worried about security issues resulting from the fact
that time will pass, and the process may d
Christos Zoulas wrote:
> Don't you need a getuid2(pid_t pid)?
uid, gid and pid are passed inthe FUSE header, so we aready have them.
> Why don't you add separate fuse messages to send and retrieve this
> information? Then the kernel can notify if these have changed...
That adds a lot of state
In article <20111213141930.ge15...@homeworld.netbsd.org>,
Emmanuel Dreyfus wrote:
>Hello
>
>FUSE has no way to send the calling process secondary groups to the
>filesystem. A filesystem that wants this operation currently has to
>open a /proc file, read and parse the string represnetation of the
On Tue, Dec 13, 2011 at 02:19:30PM +, Emmanuel Dreyfus wrote:
> A third way was suggested on the fuse-devel mailing list: adding a
> system call to retreive a process' secondary groups. The prototype
> would be moddled on getgroups(2):
>
> int getgroups2(int gidsetlen, gid_t *gidset,
Hello
FUSE has no way to send the calling process secondary groups to the
filesystem. A filesystem that wants this operation currently has to
open a /proc file, read and parse the string represnetation of the
groups, and close the file.
This is not very good performance-wise, as the filesystem
24 matches
Mail list logo