[gpfsug-discuss] does ganesha deny access for unknown UIDs?

Simon Thompson S.J.Thompson at bham.ac.uk
Fri Jan 25 18:28:27 GMT 2019


Note there are other limitations introduced by setting manage_gids. Whilst you get round the 16 group limit, instead ACLs are not properly interpreted to provide user access when an ACL is in place. In a PMR were told the only was around this would be to user sec_krb.

Simon
________________________________________
From: gpfsug-discuss-bounces at spectrumscale.org [gpfsug-discuss-bounces at spectrumscale.org] on behalf of Andy Kurth [andy_kurth at ncsu.edu]
Sent: 25 January 2019 16:08
To: gpfsug main discussion list
Subject: Re: [gpfsug-discuss] does ganesha deny access for unknown UIDs?

I believe this is occurring because of the manage_gids=TRUE setting.  The purpose of this setting is to overcome the AUTH_SYS 16 group limit.  If true, Ganesha takes the UID and resolves all of the GIDs on the server.  If false, the GIDs sent by the client are used.

I ran a quick test by creating a local user on the client and exporting 2 shares with 777 permissions, one with manage_gids=TRUE and one with FALSE.

The user could view the share and create files with manage_gids=FALSE.  ganesha.log showed that it tried and failed to resolve the UID to a name, but allowed the operation nonetheless:

2019-01-25 10:19:03 : epoch 0001004c : gpfs-proto.domain : ganesha.nfsd-123297[work-30] xdr_encode_nfs4_princ :ID MAPPER :INFO :nfs4_uid_to_name failed with code -2.
2019-01-25 10:19:03 : epoch 0001004c : gpfs-proto.domain : ganesha.nfsd-123297[work-30] xdr_encode_nfs4_princ :ID MAPPER :INFO :Lookup for 779 failed, using numeric owner

With manage_gids=TRUE, the client received permission denied and ganesha.log showed the GID query failing:

2019-01-25 10:19:27 : epoch 0001004c : gpfs-proto.domain : ganesha.nfsd-123297[work-39] uid2grp_allocate_by_uid :ID MAPPER :INFO :No matching password record found for uid 779
2019-01-25 10:19:27 : epoch 0001004c : gpfs-proto.domain : ganesha.nfsd-123297[work-39] nfs_req_creds :DISP :INFO :Attempt to fetch managed_gids failed

Hope this helps,
Andy Kurth / NC State University

On Thu, Jan 24, 2019 at 9:36 AM Billich Heinrich Rainer (PSI) <heiner.billich at psi.ch<mailto:heiner.billich at psi.ch>> wrote:
Hello,

a local account on a nfs client couldn’t write to a ganesha nfs export even with directory permissions 777. The solution was to create the account on the ganesha servers, too.

Please can you confirm that this is the intended behaviour? is there an option to change this and to map unknown accounts to nobody instead? We often have embedded Linux appliances or similar as nfs clients which need to place some data on the nfs exports  using uid/gid of local accounts.

We manage gids on the server side and allow NFS v3 client access only.

I crosspost this to ganesha support and to the gpfsug mailing list.

Thank you,

Heiner Billich

ganesha version: 2.5.3-ibm028.00.el7.x86_64

the ganesha config

CacheInode
{
        fd_hwmark_percent=60;
        fd_lwmark_percent=20;
        fd_limit_percent=90;
        lru_run_interval=90;
        entries_hwmark=1500000;
}
NFS_Core_Param
{
        clustered=TRUE;
        rpc_max_connections=10000;
        heartbeat_freq=0;
        mnt_port=33247;
        nb_worker=256;
        nfs_port=2049;
        nfs_protocols=3,4;
        nlm_port=33245;
        rquota_port=33246;
        rquota_port=33246;
        short_file_handle=FALSE;
        mount_path_pseudo=true;
}
GPFS
{
        fsal_grace=FALSE;
        fsal_trace=TRUE;
}
NFSv4
{
        delegations=FALSE;
        domainname=virtual1.com<http://virtual1.com>;
        grace_period=60;
        lease_lifetime=60;
}
Export_Defaults
{
        access_type=none;
        anonymous_gid=-2;
        anonymous_uid=-2;
        manage_gids=TRUE;
        nfs_commit=FALSE;
        privilegedport=FALSE;
        protocols=3,4;
        sectype=sys;
        squash=root_squash;
        transports=TCP;
}

one export

# === START /**** id=206 nclients=3 ===
EXPORT {
            Attr_Expiration_Time=60;
            Delegations=none;
            Export_id=206;
            Filesystem_id=42.206;
            MaxOffsetRead=18446744073709551615;
            MaxOffsetWrite=18446744073709551615;
            MaxRead=1048576;
            MaxWrite=1048576;
            Path="/****";
            PrefRead=1048576;
            PrefReaddir=1048576;
            PrefWrite=1048576;
            Pseudo="/****";
            Tag="****";
            UseCookieVerifier=false;
            FSAL {
                        Name=GPFS;
            }
            CLIENT {
                # === ****/X12SA ===
                        Access_Type=RW;
                        Anonymous_gid=-2;
                        Anonymous_uid=-2;
                        Clients=X.Y.A.B/24;
                        Delegations=none;
                        Manage_Gids=TRUE;
                        NFS_Commit=FALSE;
                        PrivilegedPort=FALSE;
                        Protocols=3;
                        SecType=SYS;
                        Squash=Root;
                        Transports=TCP;
            }
….
--
Paul Scherrer Institut
Heiner Billich
System Engineer Scientific Computing
Science IT / High Performance Computing
WHGA/106
Forschungsstrasse 111
5232 Villigen PSI
Switzerland

Phone +41 56 310 36 02
heiner.billich at psi.ch<mailto:heiner.billich at psi.ch>
https://www.psi.ch


_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org<http://spectrumscale.org>
http://gpfsug.org/mailman/listinfo/gpfsug-discuss


--
Andy Kurth
Research Storage Specialist
NC State University
Office of Information Technology

P: 919-513-4090
311A Hillsborough Building
Campus Box 7109
Raleigh, NC 27695



More information about the gpfsug-discuss mailing list