[OpenAFS-devel] GIDs and file server permission checks

[Nathaniel W Filardo]

--DV2QSXXe90Wp/UR6
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

In-Reply-To: <1414283690.18702.12.camel@vikktakkht>

On Sun, Oct 26, 2014 at 12:35:10AM +0000, Brandon Allbery wrote:
> On Sat, 2014-10-25 at 20:30 -0400, Nathaniel W Filardo wrote:
> >
> > Well, cache managers can only be trusted to take away permissions if
> > they're trusted; since they're running on arbitrary machines and
> > contacting our servers, that's surely not the case.  So I think I stand
> > by my statement,
>
> You misunderstand, perhaps; the taking away often happens in the VFS layer
> of the OS, and the cache manager has no say in it. I believe this is what
> you're seeing on Debian.

No, I do not think I misunderstand; the same assertion holds about other
people's kernels; the servers can't trust them to enforce some bit of
permission logic, either.  In any case, this is far more electrons
manipulated (one can hardly say "ink spilled") over a dubious comment than I
had intended, so, moving on...

Alas, no, the VFS is clearly passing requests through; while some clients m=
ay
be broken in this regard, mine is not; I truly am seeing a server side
rejection.  Perhaps the "using my admin hat" asides in my last post were not
sufficiently clear, so consider these two transcripts, run in adjacent xter=
ms,
one after the other, as the same local UNIX user.

pf% export KRB5CCNAME=3DKEYRING:session
pf% pagsh -c $SHELL
pf% kinit nwf@ACM.JHU.EDU
Password for nwf@ACM.JHU.EDU:
pf% cd /afs/acm.jhu.edu/user/nwf
pf% aklog .
pf% touch test
pf% ls -l test
-rw-r--r-- 1 1063 nwf 0 Oct 26 13:11 test
pf% chgrp users test
chgrp: changing group of =E2=80=98test=E2=80=99: Operation not permitted

pf% export KRB5CCNAME=3DKEYRING:session
pf% pagsh -c $SHELL
pf% kinit nwf/admin@ACM.JHU.EDU
Password for nwf/admin@ACM.JHU.EDU:
pf% cd /afs/acm.jhu.edu/user/nwf
pf% aklog .
pf% chgrp users test
pf% ls -l test
-rw-r--r-- 1 1063 users 0 Oct 26 13:11 test

Please note that my local user is not a member of the users group,
so _POSIX_CHOWN_RESTRICTED is not relevant here:

pf% id -a
uid=3D1000(nwf) gid=3D1000(nwf) groups=3D1000(nwf),20(dialout),24(cdrom),25=
(floppy),27(sudo),29(audio),44(video),46(plugdev),111(netdev),116(powerdev)=
,124(fuse),1095163749

If even the transcript is unconvincing, here's the tail end of a packet dump
taken during the unsuccessful chgrp command in the first chunk:

13:30:26.718660 IP (tos 0x0, ttl 64, id 46277, offset 0, flags [none], prot=
o UDP (17), length 96)
    172.29.7.103.7001 > 128.220.251.36.7000: [udp sum ok]  rx data cid 6075=
47b4 call# 3 seq 1 ser 6 <client-init>,<last-pckt> fs call store-status fid=
 536871072/212/48335 StoreStatus group 100 (68)
13:30:26.805885 IP (tos 0x0, ttl 52, id 27775, offset 0, flags [none], prot=
o UDP (17), length 60)
    128.220.251.36.7000 > 172.29.7.103.7001: [udp sum ok]  rx abort cid 607=
547b4 call# 3 seq 0 ser 5 fs reply store-status error #49733376 (32)

Just in case there's still any confusion, that's my client transmitting a
request to store gid 100 for the fid of the test file,

pf% fs exa test
File test (536871072.212.48335) contained in volume 536871072

and the server responding with an error return of 49733376, which is indeed=
 the
UAE table encoding of EPERM, which is as reported in the transcript.

If POSIX environments cannot be faithfully trusted to execute chown and chg=
rp
calls in AFS due to things like _POSIX_CHOWN_RESTRICTED, that should, at the
minimum, be an argument for building 'fs chown' and 'fs chgrp' on POSIX
machines as well as on Windows and I will be happy to submit a patch that
copies code from WINNT/afsd/fs.c to src/venus/fs.c.  That is, however, a
separate concern from the busted server-side permissions checking I initial=
ly
reported.

Cheers,
--nwf;

--DV2QSXXe90Wp/UR6
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlRNM3IACgkQTeQabvr9Tc/qOwCfX96YjCqo6kp1L9kAOMdnv84l
OowAn2txuGvy6rWh2abjoqSbTh/SQRWC
=0W2x
-----END PGP SIGNATURE-----

--DV2QSXXe90Wp/UR6--