[Gluster-users] File system permissions (groups) -- need to transition to NFS?

[Andrew Séguin]

Hi,

Many thanks for the in depth explanation!

I understand this as (put simply) the problem is not in FUSE, nor
really Gluster, but in the need to support the combination of the
native and NFS protocols.

Two thoughts (free ideas to take or throw out at will, I've not had
the chance to even think of looking into the code yet):

A) how about an option to set it at the volume level if the
administrator knows they will use one or the other protocol
exclusively (ex: set the flag via configuration, or if NFS were to be
disabled)? Seems like a potential quick fix, but probably not the best
long term.

B) how about bumping the protocol but making the new server version
compatible with the previous? I'm thinking about:
- Gluster client C would initiate the connection with version X of the
protocol, with the server A; server A sets an internal connection
state/flag that the protocol used is Gluster v.X / NFS / CIFS ...
- Situation 1: Server A detects the file needed is on a brick on
server B, therefore forwarding a request to server B via protocol
Gluster v.X+1. Gluster B detects protocol Gluster v.X+1, and reads a
flag about the protocol that was used.
- Situation 2: Server A detects the file needed is on a brick it
controls, therefore using permissions model as needed.
I assume that the protocol version is embedded in the requests or at
least connection requests... the flag could be based on the protocol
used to access the first server, or could be based on "file permission
check necessary or not".


Once again, thanks for the information and the work of all the devs!

Andrew



On Thu, Jan 20, 2011 at 9:28 PM, Anand Avati <anand.avati at gmail.com> wrote:
> 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@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
>
>