Hi all,
The attached patch fixes the problem where Linux NFS server is not
able to serve clients with FQDN longer than 49 characters (altough
FQDN can be up to 255 characters, and I am not counting exports to
subnet or wildcard, which can add to the total length). The patch
also fixes at least the following two bugs from RH bugzilla:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=127521
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=135109
I am sorry to repost this, but I have got no feedback from NFS maintainers,
while I've got postitive feedback from three people whose problems
was fixed by this patch. NFS maintaners - are you alive? If not,
Linus, please apply this patch. Thanks,
-Yenya
Patch relative to 2.6.9:
Signed-Off-By: Jan "Yenya" Kasprzak <[email protected]>
--- linux-2.6.9/net/sunrpc/svcauth_unix.c.orig 2004-10-26 15:47:51.497924576 +0200
+++ linux-2.6.9/net/sunrpc/svcauth_unix.c 2004-10-26 16:01:20.121995032 +0200
@@ -150,11 +150,13 @@
}
static struct ip_map *ip_map_lookup(struct ip_map *, int);
+#define DOMAINNAME_MAX 1024 /* FQDN + possible aliases/subnets/wildcards */
+#define CLASS_MAX 50
static int ip_map_parse(struct cache_detail *cd,
char *mesg, int mlen)
{
/* class ipaddress [domainname] */
- char class[50], buf[50];
+ static char class[CLASS_MAX], buf[DOMAINNAME_MAX];
int len;
int b1,b2,b3,b4;
char c;
@@ -167,13 +169,13 @@
mesg[mlen-1] = 0;
/* class */
- len = qword_get(&mesg, class, 50);
+ len = qword_get(&mesg, class, CLASS_MAX);
if (len <= 0) return -EINVAL;
if (len >= sizeof(ipm.m_class))
return -EINVAL;
/* ip address */
- len = qword_get(&mesg, buf, 50);
+ len = qword_get(&mesg, buf, DOMAINNAME_MAX);
if (len <= 0) return -EINVAL;
if (sscanf(buf, "%u.%u.%u.%u%c", &b1, &b2, &b3, &b4, &c) != 4)
@@ -184,7 +186,7 @@
return -EINVAL;
/* domainname, or empty for NEGATIVE */
- len = qword_get(&mesg, buf, 50);
+ len = qword_get(&mesg, buf, DOMAINNAME_MAX);
if (len < 0) return -EINVAL;
if (len) {
--
| Jan "Yenya" Kasprzak <kas at {fi.muni.cz - work | yenya.net - private}> |
| GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/ Czech Linux Homepage: http://www.linux.cz/ |
> Whatever the Java applications and desktop dances may lead to, Unix will <
> still be pushing the packets around for a quite a while. --Rob Pike <
On Tue, Oct 26, 2004 at 04:11:48PM +0200, Jan Kasprzak wrote:
> I am sorry to repost this, but I have got no feedback from NFS maintainers,
> while I've got postitive feedback from three people whose problems
> was fixed by this patch. NFS maintaners - are you alive? If not,
> Linus, please apply this patch. Thanks,
Hm. For some reason, your message never made it into my mailbox, though
I can see it in the marc.theaimsgroup.com archives of the nfs list.
Changing those buffers to static strikes me as potentially dangerous--we
currently call the ->parse() methods under a semaphore, so it's safe for
now, but that might change some day and then there'll be an ugly race
condition.
Could you check whether the following fixes your problem?--b.
Problem identified by Jan Kasprzak.
Limit on domainname size (currently 50) is too small.
Just use the beginning of input buffer as scratch space for it, and
save a little stack space while we're at it.
Signed-off-by: J. Bruce Fields
---
linux-2.6.10-rc1-bfields/net/sunrpc/svcauth_unix.c | 14
linux-2.6.10-rc1-bfields/net/sunrpc/svcauth_unix.c.orig | 511 ++++++++++++++++
2 files changed, 518 insertions(+), 7 deletions(-)
diff -puN net/sunrpc/svcauth_unix.c~fqdn_length_fix net/sunrpc/svcauth_unix.c
--- linux-2.6.10-rc1/net/sunrpc/svcauth_unix.c~fqdn_length_fix 2004-10-22 23:36:50.000000000 -0400
+++ linux-2.6.10-rc1-bfields/net/sunrpc/svcauth_unix.c 2004-10-22 23:37:47.000000000 -0400
@@ -150,11 +150,14 @@ static void ip_map_request(struct cache_
}
static struct ip_map *ip_map_lookup(struct ip_map *, int);
+
static int ip_map_parse(struct cache_detail *cd,
char *mesg, int mlen)
{
/* class ipaddress [domainname] */
- char class[50], buf[50];
+ /* should be safe just to use the start of the input buffer
+ * for scratch: */
+ char *buf = mesg;
int len;
int b1,b2,b3,b4;
char c;
@@ -167,13 +170,11 @@ static int ip_map_parse(struct cache_det
mesg[mlen-1] = 0;
/* class */
- len = qword_get(&mesg, class, 50);
+ len = qword_get(&mesg, ipm.m_class, sizeof(ipm.m_class));
if (len <= 0) return -EINVAL;
- if (len >= sizeof(ipm.m_class))
- return -EINVAL;
/* ip address */
- len = qword_get(&mesg, buf, 50);
+ len = qword_get(&mesg, buf, mlen);
if (len <= 0) return -EINVAL;
if (sscanf(buf, "%u.%u.%u.%u%c", &b1, &b2, &b3, &b4, &c) != 4)
@@ -184,7 +185,7 @@ static int ip_map_parse(struct cache_det
return -EINVAL;
/* domainname, or empty for NEGATIVE */
- len = qword_get(&mesg, buf, 50);
+ len = qword_get(&mesg, buf, mlen);
if (len < 0) return -EINVAL;
if (len) {
@@ -194,7 +195,6 @@ static int ip_map_parse(struct cache_det
} else
dom = NULL;
- strcpy(ipm.m_class, class);
ipm.m_addr.s_addr =
htonl((((((b1<<8)|b2)<<8)|b3)<<8)|b4);
ipm.h.flags = 0;
_
J. Bruce Fields wrote:
: Changing those buffers to static strikes me as potentially dangerous--we
: currently call the ->parse() methods under a semaphore, so it's safe for
: now, but that might change some day and then there'll be an ugly race
: condition.
:
: Could you check whether the following fixes your problem?--b.
:
Yes, it is OK with this patch. Thanks,
-Yenya
--
| Jan "Yenya" Kasprzak <kas at {fi.muni.cz - work | yenya.net - private}> |
| GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/ Czech Linux Homepage: http://www.linux.cz/ |
> Whatever the Java applications and desktop dances may lead to, Unix will <
> still be pushing the packets around for a quite a while. --Rob Pike <
Jan Kasprzak wrote:
: J. Bruce Fields wrote:
: : Changing those buffers to static strikes me as potentially dangerous--we
: : currently call the ->parse() methods under a semaphore, so it's safe for
: : now, but that might change some day and then there'll be an ugly race
: : condition.
: :
: : Could you check whether the following fixes your problem?--b.
: :
: Yes, it is OK with this patch. Thanks,
:
It seems this patch did not make it into Linus' tree
(at least it is not in 2.6.10-rc2). Can you resend it to Linus, please?
Thanks,
-Yenya
--
| Jan "Yenya" Kasprzak <kas at {fi.muni.cz - work | yenya.net - private}> |
| GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/ Czech Linux Homepage: http://www.linux.cz/ |
> Whatever the Java applications and desktop dances may lead to, Unix will <
> still be pushing the packets around for a quite a while. --Rob Pike <
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Thu, Nov 25, 2004 at 01:29:02PM +0100, Jan Kasprzak wrote:
> It seems this patch did not make it into Linus' tree
> (at least it is not in 2.6.10-rc2). Can you resend it to Linus, please?
It's in recent -bk snapshots.--b.
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs