Bug 507266 - Non UTF-8 names rejected by NFS server on RHEL 4 but not RHEL 5 and TOT.
Non UTF-8 names rejected by NFS server on RHEL 4 but not RHEL 5 and TOT.
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.8
All Linux
medium Severity medium
: rc
: 4.9
Assigned To: Jeff Layton
Red Hat Kernel QE team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-21 23:09 EDT by Harshula Jayasuriya
Modified: 2010-10-23 06:12 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-06-24 13:30:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
testcase from Fujitsu (1.12 KB, text/x-csrc)
2009-06-21 23:12 EDT, Harshula Jayasuriya
no flags Details
patch from Fujitsu (4.91 KB, patch)
2009-06-21 23:13 EDT, Harshula Jayasuriya
no flags Details | Diff

  None (edit)
Description Harshula Jayasuriya 2009-06-21 23:09:52 EDT
The function check_utf8() is in RHEL 4, but it has been removed since ~ 2.6.11 from kernel.org kernels. Furthermore, RHEL 5 does not contain this function. Fujitsu would like RHEL 4 NFS servers to be consistent with the RHEL 5 NFS servers by removing the UTF-8 check.

* Reference to the original patch by Bruce Fields:
http://www.linux-nfs.org/pipermail/nfsv4/2005-February/001175.html


Details from Fujitsu:
------------------------------------------------------------
RHN System ID:

Customer Contact Name:

 Ishikawa Yoshitaka

Description of Problem:

 Almost all the file systems do not check the filename be operated is valid
 UTF-8 or not, for example ext2/ext3/NFSv2/NFSv3, etc.
 If an ext3 file (directory) whose name is invalid UTF-8 and be exported
 through NFSv4, Client can not operate this file(directory).
 So we'd better not to do this check.

 About this problem, the maintainer of NFSv4 'J. Bruce Fields' said:
 -------------------------
 RFC3530 says NFSv4 filenames are in UTF-8, and that servers "should" reject
 filenames that aren't valid UTF-8.  Currently we do some incomplete UTF-8
 checking, but this turns out to be more of a hindrance than a help--if we
 export a file system with non-UTF8 names, things break.  We might be able to
 help things if we had some idea of the exported file system's charset and could
 do some translation.  For now, though, the simplest solution by far seems to be
 just to remove the UTF-8 checks, making NFSv4's behavior just like NFSv2/v3's.

Version-Release number of selected component:

 Red Hat Enterprise Linux Version Number: RHEL4
 Release Number:                          4.8 snapshot5
 Architecture:                            x86_64
 Kernel Version:                          kernel-2.6.9-88.EL
 Related Package Version:                 None
 Related Middleware / Application:        None

Drivers or hardware or architecture dependency:

 None

How reproducible:

 Every time

Step to Reproduce:

 Server Settings:
   # cat /etc/exports
   /tmp *(rw,insecure,fsid=0,no_root_squash)

 Client:
   Execute following commands to reproduce:

   Step1:mount the nfsv4 fs and enter the mount dir
       # mount -t nfs4 [server]:/ /mnt
       # cd /mnt
   Step2:compile the reproduction program:
       # cp $somedir/check_utf8.c .
       # gcc -o check_utf8 check_utf8.c
   Step3:execute the reproduction program
       # ./check_utf8

Actual Results:

 Operations are rejected by NFS Server.

 # ./check_utf8
 Error: mkdir '??' failed. (Invalid argument)
 Error: opendir '??' failed. (Invalid argument)
 Error: rmdir '??' failes. (Invalid argument)
 Error: open '??' failed. (Invalid argument)
 Error: rename '??' to '??' failed. (Invalid argument)
 Error: unlink '??' failed. (Invalid argument)

Expected Results:

 Operations can be dealt by NFS Server.

 # ./check_utf8
 mkdir '??' ok.
 opendir '??' ok.
 rmdir '??' ok.
 open '??' ok.
 rename '??' to '??' ok.
 unlink file '??' ok.


Summary of actions taken to resolve issue:

 None

Location of diagnostic data:

 None

Hardware configuration:

 Model:       PRIMERGY TX150 S5
 CPU Info:    Intel(R) Xeon(R) CPU   3040  @ 1.86GHz
 Memory Info: 6GB

Business Impact:

 None.
 Target Release: 4.9
 Errata Request: No
 Hotfix Request: No
------------------------------------------------------------
Comment 1 Harshula Jayasuriya 2009-06-21 23:12:10 EDT
Created attachment 348844 [details]
testcase from Fujitsu
Comment 2 Harshula Jayasuriya 2009-06-21 23:13:38 EDT
Created attachment 348845 [details]
patch from Fujitsu
Comment 3 Harshula Jayasuriya 2009-06-22 02:14:46 EDT
I was able to reproduce this problem and the patch resolves the problem.
Comment 4 Peter Staubach 2009-06-22 09:56:55 EDT
Hopefully, if we are going to remove this support, then no customers were
depending upon it for reasons of their own...
Comment 5 Jeff Layton 2009-06-22 10:10:34 EDT
I haven't tested it yet, but the patch looks fairly straightforward. I don't forsee any technical issues with it. The only real questions are:

1) is this a critical enough problem to warrant a fix in RHEL4 now that it's in maintenance mode?

2) is anyone actually depending on this behavior? It seems doubtful, but we have to consider the possibility that some apps that may be expecting EINVAL here will suddenly fail when they don't get an error.

For now, I'll plan to add this to my test kernels so that it gets some soak time there.

Before I propose this for inclusion however, I'll need some justification for this change. The fact that the bug description says "Business Impact: none" would seem to argue against its inclusion.
Comment 6 Harshula Jayasuriya 2009-06-23 21:59:16 EDT
From the customer:
--------------------------------------------------------
Yes, there is no customer who is perplexed with this problem. So I will leave whether to the fix.
--------------------------------------------------------
Comment 7 Jeff Layton 2009-06-24 13:13:28 EDT
In that case, I move that we close this as WONTFIX. Even though it sounds fairly harmless, it is a behavior change. There isn't a compelling reason to risk breaking applications that may be dependent on the current behavior. If that situation changes then reopen this bug and we can reevaluate it.
Comment 8 RHEL Product and Program Management 2009-06-24 13:30:10 EDT
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.

Note You need to log in before you can comment on or make changes to this bug.