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 may
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 xterms,
one after the other, as the same local UNIX user.
pf% export KRB5CCNAME=KEYRING:session
pf% pagsh -c $SHELL
pf% kinit n...@acm.jhu.edu
Password for n...@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 ‘test’: Operation not permitted
pf% export KRB5CCNAME=KEYRING:session
pf% pagsh -c $SHELL
pf% kinit nwf/ad...@acm.jhu.edu
Password for nwf/ad...@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=1000(nwf) gid=1000(nwf)
groups=1000(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], proto
UDP (17), length 96)
172.29.7.103.7001 > 128.220.251.36.7000: [udp sum ok] rx data cid 607547b4
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], proto
UDP (17), length 60)
128.220.251.36.7000 > 172.29.7.103.7001: [udp sum ok] rx abort cid
607547b4 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 chgrp
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 initially
reported.
Cheers,
--nwf;
pgpmQwLqtUNXh.pgp
Description: PGP signature
