On Jun 2, 2013, at 9:00 PM, Neil Brown <neilb@xxxxxxx> wrote: > As you probably know, since 3.7 (I think) Linux NFS has explicitly > asked for machine credentials for certain requests rather than asking > for root credentials as is previously did. > This causes a regression for people who don't have any machine > credentials configured and use "gssd -n". > > I gather this was discussed on the mailing list earlier this year but > not resolved. It's resolved in 3.10-rc. The kernel will attempt to use krb5i for lease management operations. If that fails because there is no keytab available, it falls back to using AUTH_SYS. > I would like to re-awaken the issue and offer a resolution (which has > been tested and found effective by a customer). > > Hence these three patches. The first two are minor issues that I > stumbled over while trying to understand the problem and are not > critical but probably should be fixed. > > The third addresses the above mentioned issue. It introduces a > variable "machine_uses_root_credentials" which is similar to the > current "root_uses_machine_credentials". It also adds a "-N" flag to > set this variable. > > I'm not certain what the defaults should be. For backward > compatibility it would be best if '-n' set the this new variable as > well as clearing the old one, but then I'm not sure what exactly -N > should do. > > Comments welcome. > > Thanks, > NeilBrown > > > > --- > > Neil Brown (3): > krb5_utils: remove redundant array size. > krb5_util: don't give up on machine credential if hostname not available. > gssd: add -N option to use root credentials as machine credentials. > > > utils/gssd/gssd.c | 9 ++++++--- > utils/gssd/gssd.h | 1 + > utils/gssd/gssd.man | 13 ++++++++++++- > utils/gssd/gssd_proc.c | 12 +++++++----- > utils/gssd/krb5_util.c | 10 +++++++--- > 5 files changed, 33 insertions(+), 12 deletions(-) > > -- > Signature > -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
