Re: [PATCH RFC 0/4] Deal with lost delegations and EKEYEXPIRED

[Andrew W Elble <aweits@rit.edu>]

> One part I’m not sure about is in nfsd4_spo_must_allow dealing with putfh like
> ops vs not putfh-like ops. I’ll have to check the spec and take a deeper look at
> that when I get some time, but maybe a brief explanation in a comment would
> help?

Will put on the list for v2.

RFC5561 2.6.3.1.1.7:
   The NFSv4.1 server MUST NOT return NFS4ERR_WRONGSEC to any operation
   other than a put filehandle operation, LOOKUP, LOOKUPP, and OPEN (by
   component name).

RFC5561 15.4:
   | NFS4ERR_WRONGSEC                  | LINK, LOOKUP, LOOKUPP, OPEN,  |
   |                                   | PUTFH, PUTPUBFH, PUTROOTFH,   |
   |                                   | RENAME, RESTOREFH

See need_wrongsec_check() (called from nfsd4_proc_compound()).

The implementation problem is that fh_verify() also calls check_nfsd_access(),
so these contortions are to avoid sending NFS4ERR_WRONGSEC on things we
shouldn't be, while still granting the spo_must_allow operation to succeed.
(based on [somthing-putfh-like]->...->[something-spo_must_allow-like]...->[end-or-putfh])

> To be honest, I've always been hazy on where in the spec the ramifications of
> SP4_MACH_CRED only covering part of a compound is discussed… I’ll take a
> look soon.

I think you mean 2.6.3.1? But it doesn't reference SP4_MACH_CRED
specifically, only 'acceptable security tuple'.

This may also be a little bit heavyweight for how the server is set up
currently. (i.e. simply changing the export (sec=krb5) to
(sec=krb5,krb5i) will eliminate the need for nfsd4_spo_must_allow()).

Thanks,

Andy

-- 
Andrew W. Elble
aweits@discipline.rit.edu
Infrastructure Engineer, Communications Technical Lead
Rochester Institute of Technology
PGP: BFAD 8461 4CCF DC95 DA2C B0EB 965B 082E 863E C912