Re: [PATCH 0/4] Add support for new RPCSEC_GSS upcall mechanism for nfsd

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2012-07-11 at 13:27 -0400, J. Bruce Fields wrote:
> So, if the issue is: you want to be able to choose, in individual
> containers, which mechanism to use: whatever, we can probably make that
> work.

Please do then.

> If you're instead saying: it's not acceptable to use the gssproxy
> mechanism to authenticate v4.0 callbacks, the client must only ever use
> the existing mechanism: then I'd rather drop this entirely.  I don't
> want to merge an rpc server authentication upcall that's not acceptable
> for one of the rpc servers.

If it goes in, I want it to be optional so that it doesn't break working
setups. I also want upgrades/downgrades to be as painless as possible. 

See for instance the idmapper changes in 3.5 which are totally
transparent to the user: if the admin sets up /etc/request-key.conf to
use the new id_resolver, then that works, otherwise we just fall back to
using the old rpc.idmapd method. There are no module parameters etc
involved.

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@xxxxxxxxxx
www.netapp.com

��.n��������+%������w��{.n�����{��w���jg��������ݢj����G�������j:+v���w�m������w�������h�����٥



[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux