Gluster users - Jan 2011 - File system permissions (groups) -- need to transition to NFS?

Hello (again),

I write after making "adjustments" to my hardware (from a single
Caviar green to a raid array of Caviar blacks). I would still love
feedback about users with smaller systems for storing user home
directories in my range of hardware, as to expectations/sizing, etc.
(maybe in response to my mail from yesterday?)

One concrete problem I'm trying to resolve at the moment is with file
system permissions. In short, a user with gid=X and groups=Y,Z can
work in folders that are owned by group X and permissions 770, but can
not read/list the contents of a directory owned by group Y and
permissions 770.

The clients mount glusterfs directly. I double checked permissions on
the gluster underlying brick's file systems and via the gluster mount;
made sure there are no ACLs (via getfacl) -- not sure what to check
else? After a bit of googling I found only a mail to this mailling
list from December without answer
(http://www.mail-archive.com/gluster-users at gluster.org/msg04478.html).

In the end, I managed to find the bug report
http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=2183, which
(per the comments) is still open in 3.1.2 -- but maybe it can't even
be fixed at all by the Gluster devs (if it's really FUSE that is the
problem as I understood from the comments)?

Two questions then:
- Is it really a FUSE or a Gluster issue that the additional groups aren't
read?

- Thinking about switching to NFS on the clients, does the built-in
NFS service create more or less work for a distributed replicated
system (due to a shifting in the responsibility for the
synchronization?) on the servers? I'd tend to think yes - but if yes,
relatively speaking, how much? (at peaks during synchronization, I've
seen upto overall 50% CPU use  of a dual quad-core Xeon system).

Input is welcome!

Andrew

The problem is this -

FUSE already does the right permission (including aux groups) check before
forwarding requests to gluster. But it does not forward the list of aux
groups along with the request to gluster.

NFS expects gluster to do permission checks (even though the NFS client does
some obvious checks, it is still up to the server side to guarantee
permission checks).

Gluster bricks, today, have no way to differentiate between an NFS request
and a FUSE request. access-control translator must kick in for NFS requests
only. To bring about differentiation in calls, we would have to bump up
protocol version. In the mean time we are figuring out an non-intrusive way
to overload some other field and yet be backward compatible with
non-overloaded clients.

Avati

On Wed, Jan 19, 2011 at 3:19 AM, Andrew S?guin <aseguo at gmail.com>
wrote:
> Hello (again),
>
> I write after making "adjustments" to my hardware (from a single
> Caviar green to a raid array of Caviar blacks). I would still love
> feedback about users with smaller systems for storing user home
> directories in my range of hardware, as to expectations/sizing, etc.
> (maybe in response to my mail from yesterday?)
>
> One concrete problem I'm trying to resolve at the moment is with file
> system permissions. In short, a user with gid=X and groups=Y,Z can
> work in folders that are owned by group X and permissions 770, but can
> not read/list the contents of a directory owned by group Y and
> permissions 770.
>
> The clients mount glusterfs directly. I double checked permissions on
> the gluster underlying brick's file systems and via the gluster mount;
> made sure there are no ACLs (via getfacl) -- not sure what to check
> else? After a bit of googling I found only a mail to this mailling
> list from December without answer
> (http://www.mail-archive.com/gluster-users at gluster.org/msg04478.html).
>
> In the end, I managed to find the bug report
> http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=2183, which
> (per the comments) is still open in 3.1.2 -- but maybe it can't even
> be fixed at all by the Gluster devs (if it's really FUSE that is the
> problem as I understood from the comments)?
>
> Two questions then:
> - Is it really a FUSE or a Gluster issue that the additional groups
aren't
> read?
>
> - Thinking about switching to NFS on the clients, does the built-in
> NFS service create more or less work for a distributed replicated
> system (due to a shifting in the responsibility for the
> synchronization?) on the servers? I'd tend to think yes - but if yes,
> relatively speaking, how much? (at peaks during synchronization, I've
> seen upto overall 50% CPU use  of a dual quad-core Xeon system).
>
> Input is welcome!
>
> Andrew
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://gluster.org/cgi-bin/mailman/listinfo/gluster-users
>