Bug#675176: svcgssd not working with '-n' option after lenny to squeeze upgrade
Package: nfs-kernel-server
Version: 1:1.2.2-4squeeze2
Severity: important
After upgrading a HA cluster from Lenny to Squeeze, the nfs service stopped
working.
The problem was specifying the '-n' option in RPCSVCGSSDOPTS. This
option allows the server to accept requests for any key in its keytab.
Without '-n' nodes will only accept mounts from clients using their node
name (i.e. nodeX.example.com) instead of the cluster's name
(as in nfsserver.example.com).
I applied the attached patch in order to be able to pass '-p
nfsserver.example.com' to svcgssd. This solves the problem partially
since it won't allow clients to mount an exported directory using the
node's name, which was possible previously.
The patch was posted by Eberhard Kuemmerle at the linux-nfs list and
applied upstream in 1.2.3.
The error from rpc.svcgssd in 1.2.2 using '-n' is:
May 30 12:23:51 rasca rpc.svcgssd[1991]: leaving poll
May 30 12:23:51 rasca rpc.svcgssd[1991]: handling null request
May 30 12:23:51 rasca rpc.svcgssd[1991]: WARNING: gss_set_allowable_enctypes
failed
May 30 12:23:51 rasca rpc.svcgssd[1991]: ERROR: GSS-API: error in
svcgssd_limit_krb5_enctypes: gss_set_allowable_enctypes(): No credentials were
supplied, or the credentials were unavailable or inaccessible - (0x08142008)
May 30 12:23:51 rasca rpc.svcgssd[1991]: sending null reply
May 30 12:23:51 rasca rpc.svcgssd[1991]: writing message: \x [snip]
May 30 12:23:51 rasca rpc.svcgssd[1991]: finished handling null request
May 30 12:23:51 rasca rpc.svcgssd[1991]: entering poll
This bug is still present (and worse) in 1:1.2.5-4~bpo60 which is probably
menacing Wheeze :-(
Trying to use this option on 1:1.2.5-4~bpo60 makes rpc.svcgssd fail to start
with the following error:
May 30 13:06:12 rasca rpc.svcgssd[2761]: ERROR: GSS-API: error in
gss_acquire_cred(): GSS_S_BAD_NAME (An invalid name was supplied) - Unknown
error
May 30 13:06:12 rasca rpc.svcgssd[2761]: unable to obtain nameless credentials
Thanks,
Alberto
--
Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico
agi@(inittab.org|debian.org)| en GNU/Linux y software libre
Encrypted mail preferred| http://inittab.com
Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3
Index: nfs-utils-1.2.2/utils/gssd/gss_util.c
===
--- nfs-utils-1.2.2.orig/utils/gssd/gss_util.c 2012-05-29 16:27:59.100011446 +0200
+++ nfs-utils-1.2.2/utils/gssd/gss_util.c 2012-05-29 16:28:27.312001093 +0200
@@ -191,7 +191,7 @@
}
int
-gssd_acquire_cred(char *server_name)
+gssd_acquire_cred(char *server_name, const gss_OID oid)
{
gss_buffer_desc name;
gss_name_t target_name;
@@ -207,7 +207,7 @@
name.length = strlen(server_name);
maj_stat = gss_import_name(min_stat, name,
-(const gss_OID) GSS_C_NT_HOSTBASED_SERVICE,
+oid,
target_name);
if (maj_stat != GSS_S_COMPLETE) {
Index: nfs-utils-1.2.2/utils/gssd/gss_util.h
===
--- nfs-utils-1.2.2.orig/utils/gssd/gss_util.h 2012-05-29 16:28:02.87946 +0200
+++ nfs-utils-1.2.2/utils/gssd/gss_util.h 2012-05-29 16:28:27.312001093 +0200
@@ -37,7 +37,7 @@
extern gss_cred_id_t gssd_creds;
-int gssd_acquire_cred(char *server_name);
+int gssd_acquire_cred(char *server_name, const gss_OID oid);
void pgsserr(char *msg, u_int32_t maj_stat, u_int32_t min_stat,
const gss_OID mech);
int gssd_check_mechs(void);
Index: nfs-utils-1.2.2/utils/gssd/gssd.h
===
--- nfs-utils-1.2.2.orig/utils/gssd/gssd.h 2012-05-29 16:28:06.22902 +0200
+++ nfs-utils-1.2.2/utils/gssd/gssd.h 2012-05-29 16:28:27.312001093 +0200
@@ -100,7 +100,6 @@
void handle_krb5_upcall(struct clnt_info *clp);
void handle_spkm3_upcall(struct clnt_info *clp);
void handle_gssd_upcall(struct clnt_info *clp);
-int gssd_acquire_cred(char *server_name);
void gssd_run(void);
Index: nfs-utils-1.2.2/utils/gssd/svcgssd.c
===
--- nfs-utils-1.2.2.orig/utils/gssd/svcgssd.c 2012-05-29 16:28:09.660002070 +0200
+++ nfs-utils-1.2.2/utils/gssd/svcgssd.c 2012-05-29 16:29:04.516001466 +0200
@@ -173,7 +173,7 @@
static void
usage(char *progname)
{
- fprintf(stderr, usage: %s [-n] [-f] [-v] [-r] [-i]\n,
+ fprintf(stderr, usage: %s [-n] [-f] [-v] [-r] [-i] [-p principal]\n,
progname);
exit(1);
}
@@ -186,9 +186,10 @@
int verbosity = 0;
int rpc_verbosity = 0;
int idmap_verbosity = 0;
- int opt;
+ int opt, status;
extern char *optarg;
char *progname;
+ char *principal = NULL;
while ((opt = getopt(argc, argv, fivrnp:)) != -1) {
switch (opt) {
@@ -207,6 +208,9 @@
case 'r':
rpc_verbosity++;
break;
+ case 'p':
+principal = optarg;
+break;
default:
usage(argv[0]);
break;
@@ -250,12 +254,20 @@
signal(SIGTERM, sig_die);
signal(SIGHUP, sig_hup);
- if (get_creds
Bug#675188: Change in rpc.idmapd makes clients unable to resolv users/groups
Package: nfs-kernel-server Version: 1:1.2.5-4~bpo60 Severity: important After upgrading an nfs server from 1.2.2 to 1.2.5 (from backports) all the clients lost the ability to show the correct owner/group for files and directories: -rw-rw-r-- 1 nobody nogroup0 2012-05-29 17:46 foo drwxr-xr-x 2 nobody nogroup 4096 2012-05-29 17:39 bar I tracked the problem to the way rpc.idmapd reports users and groups to the clients. From rpc.idmapd -v in 1.2.2: rpc.idmapd: nfsdcb: authbuf=gss/krb5p authtype=user rpc.idmapd: nfs4_uid_to_name: calling umich_ldap-uid_to_name rpc.idmapd: ldap_init_and_bind: version mismatch between API information and protocol version. Setting protocol version to 3 rpc.idmapd: nfs4_uid_to_name: umich_ldap-uid_to_name returned 0 rpc.idmapd: nfs4_uid_to_name: final return value is 0 rpc.idmapd: Server: (user) id 2095 - name alberto.gonzalez rpc.idmapd: nfsdcb: authbuf=gss/krb5p authtype=group rpc.idmapd: nfs4_gid_to_name: calling umich_ldap-gid_to_name rpc.idmapd: ldap_init_and_bind: version mismatch between API information and protocol version. Setting protocol version to 3 rpc.idmapd: nfs4_gid_to_name: umich_ldap-gid_to_name returned 0 rpc.idmapd: nfs4_gid_to_name: final return value is 0 rpc.idmapd: Server: (group) id 2095 - name alberto.gonzalez Whereas in 1.2.5: rpc.idmapd: nfsdcb: authbuf=gss/krb5p authtype=user rpc.idmapd: nfs4_uid_to_name: calling nsswitch-uid_to_name rpc.idmapd: nfs4_uid_to_name: nsswitch-uid_to_name returned 0 rpc.idmapd: nfs4_uid_to_name: final return value is 0 rpc.idmapd: Server : (user) id 2095 - name alberto.gonzalez@domain rpc.idmapd: nfsdcb: authbuf=gss/krb5p authtype=user rpc.idmapd: nfs4_uid_to_name: calling nsswitch-uid_to_name rpc.idmapd: nfs4_uid_to_name: nsswitch-uid_to_name returned 0 rpc.idmapd: nfs4_uid_to_name: final return value is 0 rpc.idmapd: Server : (user) id 1000 - name agi@domain rpc.idmapd: nfsdcb: authbuf=gss/krb5p authtype=group rpc.idmapd: nfs4_gid_to_name: calling nsswitch-gid_to_name rpc.idmapd: nfs4_gid_to_name: nsswitch-gid_to_name returned 0 rpc.idmapd: nfs4_gid_to_name: final return value is 0 rpc.idmapd: Server : (group) id 1000 - name agi@domain I've tried commenting out Domain = domain and setting it to its real value, (in the server's /etc/idmapd.conf) both test with the same result. I'm not saying that user@domain is not the right value for this (it probably is, don't know the RFC). But it's not the way it used to behave. It would be nice to have a way to have rpc.idmapd report users and groups as it used to, in order to avoid modifying /etc/idmapd.conf in hundreds of nfs clients as well as introducing an extra attribute (for NFSv4_name_attr and NFSv4_group_attr) in LDAP (now just using uid). I expect this bug to hit nfs (v4) servers upgrading from Squeeze to Wheezy. Thanks, Alberto -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico agi@(inittab.org|debian.org)| en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120530121311.gu4...@lib.inittab.org
Bug#622146: nfs-common: compatibility between squeeze and sid broken
On Wed, Jun 08, 2011 at 02:10:32PM -0400, Sam Hartman wrote: Hi. I was missing some context here. My suspicion is that things will work if you add permitted_enctypes = des-cbc-crc default_tgs_enctypes = des-cbc-crc to the configuration of the nfs server And make sure that the nfs principal on the NFS server has nothing but a des-cbc-crc key in the KDC database. That is kadmin.local: getprinc nfs/machine_name should only list DES keys. Hi Sam, Thanks for looking into this. I'd rather not touch anything in the server, since +100 clients are using it. If you satisfy all of these conditions then I *think* that a sid client can connect to a squeeze server. Humm, the server is (right now) lenny in my case. It may also work to make the following config changes on the client: default_tgs_enctypes = des-cbc-crc and no config changes on the server. Did that, no luck :-( I really wonder how I make it work last time... Now I have (not working): agi@lib:~$ grep cbc /etc/krb5.conf permitted_enctypes = des-cbc-crc default_tgs_enctypes = des-cbc-crc agi@lib:~$ grep weak /etc/krb5.conf allow_weak_crypto = yes And only the des-cbc-crc:normal key on this hosts' keytab. Regards, Alberto -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico agi@(inittab.org|debian.org)| en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110609110446.gj3...@lib.inittab.org
Bug#622146: Not working...
Ok, got tired of this now. I don't know how it worked a couple of days ago, I'm not able to get it to work now. Either with 1.9 or 1.9.1. Only the des-cbc-md5 or des-cbc-crc keys in the client's keytab, with both: allow_weak_crypto = yes permitted_enctypes = des-cbc-(md5|crc) Or just with allow_weak_crypto No way to mount, with the known errors on the server. I'll play with this again in some days, sshfs will do the job for the time being. -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico agi@(inittab.org|debian.org)| en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110608102313.gk3...@lib.inittab.org
Bug#622146: nfs-common: compatibility between squeeze and sid broken
On Tue, Jun 07, 2011 at 01:10:23PM -0400, Sam Hartman wrote: Luk == Luk Claes l...@debian.org writes: Luk On 06/06/2011 05:37 PM, Alberto Gonzalez Iniesta wrote: Adding the following line in the [libdefaults] section of /etc/krb5.conf fixed the problem for me (tm), probably not the best solution, but works: permitted_enctypes = des-cbc-md5 Luk It's probably better to set enable_weak_crypto=yes, does that Luk work? Hi. I think I gave Luk the wrong setting. It's allow_weak_crypto = yes not enable_weak_crypto = yes. You should not have to set permitted_enctypes. Enabling weak_crypto and only setting the des-cbc-crc key with ktadd in kadmin is supposed to be sufficient. I have both set: allow_weak_crypto=true permitted_enctypes = des-cbc-md5 And only the... wait I have des-cbc-md5 IIRC, not des-cbc-crc. I'll check that tomorrow. But it's not working after the last upgrade. When I posted yesterday I was running a sid versión from a couple of weeks ago. Probably 1.9, sorry can't remember now. Regards, Alberto -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico agi@(inittab.org|debian.org)| en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110607211949.ga3...@lib.inittab.org
Bug#622146: Same thing happens against lenny nfs servers
Same thing here, against a Lenny nfs server. -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico agi@(inittab.org|debian.org)| en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110606144655.ge3...@lib.inittab.org
Bug#622146: (Ugly/temp) workaround
Adding the following line in the [libdefaults] section of /etc/krb5.conf fixed the problem for me (tm), probably not the best solution, but works: permitted_enctypes = des-cbc-md5 I also exported ONLY the DES-CBC-MD5:NORMAL key for my sid host: kadmin.local: ktadd -k lib.keytab -e DES-CBC-MD5:NORMAL host/lib (probably not needed, but just to stay on the safe side) HTH, Alberto -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico agi@(inittab.org|debian.org)| en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110606153751.gf3...@lib.inittab.org
Bug#559755: Is forcing users the way to go?
Hi, I've been using cryptoloop for ~9 years. It never let me down. It may have problems, but it still useful to a lot of people. I just moved my last cryptoloop, thank to this movement by the kernel maintainers. But I think maintaining it alive and printing a warning when loading the module (just like many other software behaves on transitions) would be nicer to our users. Thanks, Alberto -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico agi@(inittab.org|debian.org)| en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100220110009.gk2...@lib.inittab.org
