Date: Fri, 5 Jul 2013 19:11:16 +0100 From: Oleg Sharoyko <osharoiko@gmail.com> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: freebsd-fs@freebsd.org Subject: Re: NFSv4 and Kerberos, group permission seem to be ignored Message-ID: <CAOSKQLHkU619n4U2LzuC-tWM6YDcprm_hmdPde8qV6qYLQZJBQ@mail.gmail.com> In-Reply-To: <1821939739.2131305.1372984627528.JavaMail.root@uoguelph.ca> References: <CAOSKQLHu8eo6wvDWFrxCZ0fA-tiOh9TpAR7Q%2B7zY9na8=k%2BChA@mail.gmail.com> <1821939739.2131305.1372984627528.JavaMail.root@uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Rick,
Thank you very much for pointing me to the code that does principal to
uid/gids translation. Turns out my problems are caused by a buffer
being too small which you have already fixed in r250176. Thank you
once again!
Regards,
Oleg
On 5 July 2013 01:37, Rick Macklem <rmacklem@uoguelph.ca> wrote:
> Oleg Sharoyko wrote:
>> Hello,
>>
>> I have a small server which runs FreeBSD 9.1 and I've is set up as
>> NFSv4 server with kerberised NFS access. My clients are linux
>> machines. It almost works as expected (mounting/accessing files)
>> except for one strange issue: it looks like group permissions on
>> files
>> and directories are being ignored. Here's an example:
>>
>> Server:
>>
>> evendim:~ % id
>> uid=1001(ols) gid=1001(ols) groups=1001(ols),0(wheel),60000(family)
>> evendim:~ % ls -l /data/file1
>> -rw-rw---- 1 root family 6 4 Jul 18:42 /data/file1
>> evendim:~ % cat /data/file1
>> test1
>> evendim:~ % ls -l /data/file2
>> -rw------- 1 ols family 6 4 Jul 18:42 /data/file2
>> evendim:~ % cat /data/file2
>> test2
>> evendim:~ % ls -l /data/file3
>> -rw-r--r-- 1 root family 6 4 Jul 18:42 /data/file3
>> evendim:~ % cat /data/file3
>> test3
>> evendim:~ % cat /etc/exports
>> V4:/ -sec=krb5
>> /data -sec=krb5
>>
> Well, here's the code snippet in gssd.c that does the principal/user
> name to gid list translation. All I can suggest is putting this in a
> little test program on the server and then running it as "root", to
> see if it generates the results you would expect.
> (Btw, NGRPS is defined as 16 in a .h file in /usr/include/rpc. I suspect
> that should be increased and the code should check for a -1 return
> from getgrouplist(). However, you don't seem to exceed 16 groups.
> It also assumes that sizeof(gid_t) == sizeof(int).
> A little weird and I'm not sure that is true for all arches?
> Did I remember to mention I wasn't the author of this?;-)
>
> if (pw) {
> int len = NGRPS;
> int groups[NGRPS];
> result->gid = pw->pw_gid;
> getgrouplist(pw->pw_name, pw->pw_gid,
> groups, &len);
> result->gidlist.gidlist_len = len;
> result->gidlist.gidlist_val =
> mem_alloc(len * sizeof(int));
> memcpy(result->gidlist.gidlist_val, groups,
> len * sizeof(int));
> gssd_verbose_out("gssd_pname_to_uid: mapped"
> " to uid=%d, gid=%d\n", (int)result->uid,
> (int)result->gid);
> } else {
>
>> Client:
>>
>> sherlock:~ % id
>> uid=1000(ols) gid=1000(ols)
>> groups=1000(ols),4(adm),20(dialout),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),109(netdev),110(bluetooth),113(fuse),116(scanner),118(kismet),60000(family)
>> sherlock:~ % sudo mount -v -t nfs4 -o sec=krb5
>> evendim.sharoyko.net:/data /mnt
>> mount.nfs4: timeout set for Thu Jul 4 19:52:16 2013
>> mount.nfs4: trying text-based options
>> 'sec=krb5,addr=192.168.1.3,clientaddr=192.168.1.128'
>> sherlock:~ % ls -l /mnt/file1
>> -rw-rw---- 1 root family 6 Jul 4 19:42 /mnt/file1
>> sherlock:~ % cat /mnt/file1
>> cat: /mnt/file1: Permission denied
>> sherlock:~ % ls -l /mnt/file2
>> -rw------- 1 ols family 6 Jul 4 19:42 /mnt/file2
>> sherlock:~ % cat /mnt/file2
>> test2
>> sherlock:~ % ls -l /mnt/file3
>> -rw-r--r-- 1 root family 6 Jul 4 19:42 /mnt/file3
>> sherlock:~ % cat /mnt/file3
>> test3
>>
>> As you can see file2 is inaccessible while it has group read/write
>> permissions, user ols belongs to group family on both client and
>> server and user/group mapping seems to work. /data on the server is a
>> ZFS filesystem but I've also tried UFS with the same results. I've
>> also tried ACLs and ACLs for users do work while ACLs for groups
>> don't
>> seem to have any effect. Is there something that I'm doing wrong? Is
>> this an expected behaviour? I will greatly appreciate if you can help
>> me debugging this issue. I'll quote below captured packets that are
>> relevant to my attempt to access file1. As you can see access is
>> clearly denied by server but I don't understand why.
>>
>> No. Time Source Destination
>> Protocol Length Info
>> 109 5.649608 192.168.1.128 192.168.1.3 NFS
>> 258 V4 Call (Reply In 110) LOOKUP DH:0x4dcc3776/file1
>>
>> Frame 109: 258 bytes on wire (2064 bits), 258 bytes captured (2064
>> bits)
>> Ethernet II, Src: GemtekTe_f6:cf:a1 (00:26:82:f6:cf:a1), Dst:
>> Giga-Byt_db:cd:c4 (90:2b:34:db:cd:c4)
>> Internet Protocol Version 4, Src: 192.168.1.128 (192.168.1.128), Dst:
>> 192.168.1.3 (192.168.1.3)
>> Transmission Control Protocol, Src Port: 726 (726), Dst Port: nfs
>> (2049), Seq: 3337, Ack: 3193, Len: 192
>> Remote Procedure Call, Type:Call XID:0xba073c52
>> Network File System
>> [Program Version: 4]
>> [V4 Procedure: COMPOUND (1)]
>> Tag: <EMPTY>
>> length: 0
>> contents: <EMPTY>
>> minorversion: 0
>> Operations (count: 4)
>> Opcode: PUTFH (22)
>> filehandle
>> length: 28
>> [hash (CRC-32): 0x4dcc3776]
>> decode type as: unknown
>> filehandle:
>> 9a7470c6deedeca50a0004000000000037d80a0000000000...
>> Opcode: LOOKUP (15)
>> Filename: file1
>> length: 5
>> contents: file1
>> fill bytes: opaque data
>> Opcode: GETFH (10)
>> Opcode: GETATTR (9)
>> GETATTR4args
>> attr_request
>> bitmap[0] = 0x0010011a
>> [5 attributes requested]
>> mand_attr: FATTR4_TYPE (1)
>> mand_attr: FATTR4_CHANGE (3)
>> mand_attr: FATTR4_SIZE (4)
>> mand_attr: FATTR4_FSID (8)
>> recc_attr: FATTR4_FILEID (20)
>> bitmap[1] = 0x0030a23a
>> [9 attributes requested]
>> recc_attr: FATTR4_MODE (33)
>> recc_attr: FATTR4_NUMLINKS (35)
>> recc_attr: FATTR4_OWNER (36)
>> recc_attr: FATTR4_OWNER_GROUP (37)
>> recc_attr: FATTR4_RAWDEV (41)
>> recc_attr: FATTR4_SPACE_USED (45)
>> recc_attr: FATTR4_TIME_ACCESS (47)
>> recc_attr: FATTR4_TIME_METADATA (52)
>> recc_attr: FATTR4_TIME_MODIFY (53)
>> [Main Opcode: LOOKUP (15)]
>>
>> No. Time Source Destination
>> Protocol Length Info
>> 110 5.649870 192.168.1.3 192.168.1.128 NFS
>> 370 V4 Reply (Call In 109) LOOKUP
>>
>> Frame 110: 370 bytes on wire (2960 bits), 370 bytes captured (2960
>> bits)
>> Ethernet II, Src: Giga-Byt_db:cd:c4 (90:2b:34:db:cd:c4), Dst:
>> GemtekTe_f6:cf:a1 (00:26:82:f6:cf:a1)
>> Internet Protocol Version 4, Src: 192.168.1.3 (192.168.1.3), Dst:
>> 192.168.1.128 (192.168.1.128)
>> Transmission Control Protocol, Src Port: nfs (2049), Dst Port: 726
>> (726), Seq: 3193, Ack: 3529, Len: 304
>> Remote Procedure Call, Type:Reply XID:0xba073c52
>> Network File System
>> [Program Version: 4]
>> [V4 Procedure: COMPOUND (1)]
>> Status: NFS4_OK (0)
>> Tag: <EMPTY>
>> length: 0
>> contents: <EMPTY>
>> Operations (count: 4)
>> Opcode: PUTFH (22)
>> Status: NFS4_OK (0)
>> Opcode: LOOKUP (15)
>> Status: NFS4_OK (0)
>> Opcode: GETFH (10)
>> Status: NFS4_OK (0)
>> Filehandle
>> length: 28
>> [hash (CRC-32): 0xc0a4eeb4]
>> decode type as: unknown
>> filehandle:
>> 9a7470c6deedeca50a00ed00000000001bb70d0000000000...
>> Opcode: GETATTR (9)
>> Status: NFS4_OK (0)
>> GETATTR4res
>> resok4
>> obj_attributes
>> attrmask
>> bitmap[0] = 0x0010011a
>> [5 attributes requested]
>> mand_attr: FATTR4_TYPE (1)
>> mand_attr: FATTR4_CHANGE (3)
>> mand_attr: FATTR4_SIZE (4)
>> mand_attr: FATTR4_FSID (8)
>> recc_attr: FATTR4_FILEID (20)
>> bitmap[1] = 0x0030a23a
>> [9 attributes requested]
>> recc_attr: FATTR4_MODE (33)
>> recc_attr: FATTR4_NUMLINKS (35)
>> recc_attr: FATTR4_OWNER (36)
>> recc_attr: FATTR4_OWNER_GROUP (37)
>> recc_attr: FATTR4_RAWDEV (41)
>> recc_attr: FATTR4_SPACE_USED (45)
>> recc_attr: FATTR4_TIME_ACCESS (47)
>> recc_attr: FATTR4_TIME_METADATA (52)
>> recc_attr: FATTR4_TIME_MODIFY (53)
>> attr_vals
>> mand_attr: FATTR4_TYPE (1)
>> nfs_ftype4: NF4REG (1)
>> mand_attr: FATTR4_CHANGE (3)
>> changeid: 96
>> mand_attr: FATTR4_SIZE (4)
>> size: 6
>> mand_attr: FATTR4_FSID (8)
>> fattr4_fsid
>> fsid4.major: 3329258650
>> fsid4.minor: 2783768030
>> recc_attr: FATTR4_FILEID (20)
>> fileid: 237
>> recc_attr: FATTR4_MODE (33)
>> fattr4_mode: 0660
>> 000. .... .... .... = Unknown
>> .... 0... .... .... = not SUID
>> .... .0.. .... .... = not SGID
>> .... ..0. .... .... = not save
>> swapped text
>> .... ...1 .... .... = Read
>> permission for owner
>> .... .... 1... .... = Write
>> permission for owner
>> .... .... .0.. .... = no Execute
>> permission for owner
>> .... .... ..1. .... = Read
>> permission for group
>> .... .... ...1 .... = Write
>> permission for group
>> .... .... .... 0... = no Execute
>> permission for group
>> .... .... .... .0.. = no Read
>> permission for others
>> .... .... .... ..0. = no Write
>> permission for others
>> .... .... .... ...0 = no Execute
>> permission for others
>> recc_attr: FATTR4_NUMLINKS (35)
>> numlinks: 1
>> recc_attr: FATTR4_OWNER (36)
>> fattr4_owner: root@id.sharoyko.net
>> length: 20
>> contents: root@id.sharoyko.net
>> recc_attr: FATTR4_OWNER_GROUP (37)
>> fattr4_owner_group:
>> family@id.sharoyko.net
>> length: 22
>> contents: family@id.sharoyko.net
>> fill bytes: opaque data
>> recc_attr: FATTR4_RAWDEV (41)
>> specdata1: 128
>> specdata2: 123863040
>> recc_attr: FATTR4_SPACE_USED (45)
>> space_used: 1024
>> recc_attr: FATTR4_TIME_ACCESS (47)
>> seconds: 1372963326
>> nseconds: 263434280
>> recc_attr: FATTR4_TIME_METADATA (52)
>> seconds: 1372963379
>> nseconds: 804435894
>> recc_attr: FATTR4_TIME_MODIFY (53)
>> seconds: 1372963326
>> nseconds: 264422029
>> [Main Opcode: LOOKUP (15)]
>>
>> No. Time Source Destination
>> Protocol Length Info
>> 117 8.456684 192.168.1.128 192.168.1.3 NFS
>> 322 V4 Call (Reply In 118) OPEN DH:0x4dcc3776/file1
>>
>> Frame 117: 322 bytes on wire (2576 bits), 322 bytes captured (2576
>> bits)
>> Ethernet II, Src: GemtekTe_f6:cf:a1 (00:26:82:f6:cf:a1), Dst:
>> Giga-Byt_db:cd:c4 (90:2b:34:db:cd:c4)
>> Internet Protocol Version 4, Src: 192.168.1.128 (192.168.1.128), Dst:
>> 192.168.1.3 (192.168.1.3)
>> Transmission Control Protocol, Src Port: 726 (726), Dst Port: nfs
>> (2049), Seq: 3905, Ack: 3697, Len: 256
>> Remote Procedure Call, Type:Call XID:0xbd073c52
>> Network File System
>> [Program Version: 4]
>> [V4 Procedure: COMPOUND (1)]
>> Tag: <EMPTY>
>> length: 0
>> contents: <EMPTY>
>> minorversion: 0
>> Operations (count: 5)
>> Opcode: PUTFH (22)
>> filehandle
>> length: 28
>> [hash (CRC-32): 0x4dcc3776]
>> decode type as: unknown
>> filehandle:
>> 9a7470c6deedeca50a0004000000000037d80a0000000000...
>> Opcode: OPEN (18)
>> seqid: 0x00000000
>> share_access: OPEN4_SHARE_ACCESS_READ (1)
>> share_deny: OPEN4_SHARE_DENY_NONE (0)
>> clientid: 0xcd6cc75124000000
>> owner: <DATA>
>> length: 24
>> contents: <DATA>
>> Open Type: OPEN4_NOCREATE (0)
>> Claim Type: CLAIM_NULL (0)
>> Filename: file1
>> length: 5
>> contents: file1
>> fill bytes: opaque data
>> Opcode: GETFH (10)
>> Opcode: ACCESS (3), [Check: RD MD XT XE]
>> Check access: 0x2d
>> .... ...1 = 0x01 READ: allowed?
>> .... .1.. = 0x04 MODIFY: allowed?
>> .... 1... = 0x08 EXTEND: allowed?
>> ..1. .... = 0x20 EXECUTE: allowed?
>> Opcode: GETATTR (9)
>> GETATTR4args
>> attr_request
>> bitmap[0] = 0x0010011a
>> [5 attributes requested]
>> mand_attr: FATTR4_TYPE (1)
>> mand_attr: FATTR4_CHANGE (3)
>> mand_attr: FATTR4_SIZE (4)
>> mand_attr: FATTR4_FSID (8)
>> recc_attr: FATTR4_FILEID (20)
>> bitmap[1] = 0x0030a23a
>> [9 attributes requested]
>> recc_attr: FATTR4_MODE (33)
>> recc_attr: FATTR4_NUMLINKS (35)
>> recc_attr: FATTR4_OWNER (36)
>> recc_attr: FATTR4_OWNER_GROUP (37)
>> recc_attr: FATTR4_RAWDEV (41)
>> recc_attr: FATTR4_SPACE_USED (45)
>> recc_attr: FATTR4_TIME_ACCESS (47)
>> recc_attr: FATTR4_TIME_METADATA (52)
>> recc_attr: FATTR4_TIME_MODIFY (53)
>> [Main Opcode: OPEN (18)]
>>
>> No. Time Source Destination
>> Protocol Length Info
>> 118 8.456811 192.168.1.3 192.168.1.128 NFS
>> 150 V4 Reply (Call In 117) OPEN Status: NFS4ERR_ACCES
>>
>> Frame 118: 150 bytes on wire (1200 bits), 150 bytes captured (1200
>> bits)
>> Ethernet II, Src: Giga-Byt_db:cd:c4 (90:2b:34:db:cd:c4), Dst:
>> GemtekTe_f6:cf:a1 (00:26:82:f6:cf:a1)
>> Internet Protocol Version 4, Src: 192.168.1.3 (192.168.1.3), Dst:
>> 192.168.1.128 (192.168.1.128)
>> Transmission Control Protocol, Src Port: nfs (2049), Dst Port: 726
>> (726), Seq: 3697, Ack: 4161, Len: 84
>> Remote Procedure Call, Type:Reply XID:0xbd073c52
>> Network File System
>> [Program Version: 4]
>> [V4 Procedure: COMPOUND (1)]
>> Status: NFS4ERR_ACCES (13)
>> Tag: <EMPTY>
>> length: 0
>> contents: <EMPTY>
>> Operations (count: 2)
>> Opcode: PUTFH (22)
>> Status: NFS4_OK (0)
>> Opcode: OPEN (18)
>> Status: NFS4ERR_ACCES (13)
>> [Main Opcode: OPEN (18)]
>>
>> Kind regards,
>> --
>> Oleg
>> _______________________________________________
>> freebsd-fs@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
>> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"
>>
--
Oleg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOSKQLHkU619n4U2LzuC-tWM6YDcprm_hmdPde8qV6qYLQZJBQ>