Bug 830947 - chown doesn't work on nfsv4 mounted directory
chown doesn't work on nfsv4 mounted directory
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: nfs-utils (Show other bugs)
5.8
i686 Unspecified
medium Severity medium
: rc
: ---
Assigned To: Steve Dickson
Filesystem QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-11 14:22 EDT by Thomas Cameron
Modified: 2014-02-10 10:43 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-02-10 10:43:34 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
wireshark dump (4.51 KB, application/octet-stream)
2012-06-11 14:26 EDT, Thomas Cameron
no flags Details
sosreport for Fedora 17 client (499.04 KB, application/x-xz)
2012-06-11 14:27 EDT, Thomas Cameron
no flags Details
sosreport from rhel5 server (21.30 MB, application/x-bzip)
2012-06-11 14:58 EDT, Thomas Cameron
no flags Details

  None (edit)
Description Thomas Cameron 2012-06-11 14:22:58 EDT
Description of problem:
When exporting /home from a RHEL 5.8 box using nfsv4, I am unable to chown files/directories on the client.

For instance, I strace pulseaudio and when pulse tries to fchown the directory, it gets "-1 EPERM (Operation not permitted)":

stat("/home/tcameron", {st_mode=S_IFDIR|0701, st_size=4096, ...}) = 0
getuid()                                = 1001
umask(077)                              = 022
mkdir("/home/tcameron/.pulse", 0700)    = 0
umask(022)                              = 077
open("/home/tcameron/.pulse", O_RDONLY|O_NOCTTY|O_NOFOLLOW|O_CLOEXEC) = 4
fstat(4, {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
getuid()                                = 1001
getgid()                                = 1001
fchown(4, 1001, 1001)                   = -1 EPERM (Operation not permitted)
rmdir("/home/tcameron/.pulse")          = 0
prctl(PR_GET_NAME, 0x1a19fb0, 0x1a19fb0, 0x41, 0) = 0
ioctl(2, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
write(2, "E: [pulseaudio] core-util.c: \33[1"..., 99E: [pulseaudio] core-util.c: Failed to create secure directory: Operation not permitted
) = 99
close(3)                                = 0
exit_group(1)                           = ?
+++ exited with 1 +++ 

On a locally mounted home directory, it works:

stat("/home/tcameron", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
getuid()                                = 1001
umask(077)                              = 02
mkdir("/home/tcameron/.pulse", 0700)    = -1 EEXIST (File exists)
umask(02)                               = 077
open("/home/tcameron/.pulse", O_RDONLY|O_NOCTTY|O_NOFOLLOW|O_CLOEXEC) = 7
fstat(7, {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
getuid()                                = 1001
getgid()                                = 1001
fchown(7, 1001, 1001)                   = 0
fchmod(7, 0700)                         = 0
close(7)                                = 0
lstat("/home/tcameron/.pulse", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
open("/var/lib/dbus/machine-id", O_RDONLY|O_CLOEXEC) = 7
fcntl(7, F_GETFD)                       = 0x1 (flags FD_CLOEXEC)
fstat(7, {st_mode=S_IFREG|0644, st_size=33, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe4ca771000
read(7, "7cb9d14f4151e5900b51c9080000000a"..., 4096) = 33
close(7)                                = 0
munmap(0x7fe4ca771000, 4096)            = 0
readlink("/home/tcameron/.pulse/7cb9d14f4151e5900b51c9080000000a-runtime", "/tmp/pulse-3Qn4Ou8LLkRY", 99) = 23
lstat("/tmp/pulse-3Qn4Ou8LLkRY", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
getuid()                                = 1001
unlink("/home/tcameron/.pulse/7cb9d14f4151e5900b51c9080000000a-runtime/autospawn.lock") = 0
fcntl(5, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0}) = 0
close(5)                                = 0
close(3)                                = 0
close(4)                                = 0
close(6)                                = 0
exit_group(0)                           = ?
+++ exited with 0 +++

This time, I get:
fchown(7, 1001, 1001)                   = 0
fchmod(7, 0700)                         = 0 

Here's /etc/exports on the RHEL5 NFSv4 server:

/home         172.31.100.0/255.255.255.0(rw,fsid=0,no_root_squash,sync)

Here's /etc/idmapd.conf:

[General]
Domain = tc.redhat.com
[Mapping]
Nobody-User = nobody
Nobody-Group = nobody
[Translation]
Method = nsswitch
[Static]

Here's /etc/fstab on the F17 client:
172.31.100.1:/ /home nfs4 rw,sync 0 0

I'll attach the wireshark dump as well.

Version-Release number of selected component (if applicable):
kernel-2.6.18-308.8.1.el5

How reproducible:
mount /home via nfsv4

Steps to Reproduce:
See above
  
Actual results:
Permission denied when chown-ing a file or directory

Expected results:
Permission granted.

Additional info:
None
Comment 1 Thomas Cameron 2012-06-11 14:26:46 EDT
Created attachment 590992 [details]
wireshark dump
Comment 2 Thomas Cameron 2012-06-11 14:27:34 EDT
Created attachment 590993 [details]
sosreport for Fedora 17 client
Comment 3 Thomas Cameron 2012-06-11 14:58:48 EDT
Created attachment 590998 [details]
sosreport from rhel5 server
Comment 4 J. Bruce Fields 2012-06-14 16:21:03 EDT
On a quick glance at git, it looks to me like rhel5 might be missing upstream's bdfe0d28ee4c23dec311423a34b2a3ec65b5b318 "Don't always use default mapping to "nobody"."  Steved, can you confirm that?

The upshot is that the new client maps your username to a number, expecting the server to return BADOWNER (or the less-correct but nonetheless-will-work BADNAME), in the case where it doesn't support numeric ID's.  But instead idmapd incorrectly maps the number to "nobody", and then the operation fails with EPERM.

After applying that nfs-utils patch the mapping should fail, the operation should return BAD{OWNER/NAME}, and the client should fall back on using names, which should work.
Comment 5 Enrico Scholz 2012-06-16 09:37:09 EDT
perhaps related: chown() on NFS4 does not work in Fedora 17 because wrong domain is used. bug #829362
Comment 6 RHEL Product and Program Management 2014-01-29 05:36:37 EST
This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux release.  Product Management has
requested further review of this request by Red Hat Engineering, for
potential inclusion in a Red Hat Enterprise Linux release for currently
deployed products.  This request is not yet committed for inclusion in
a release.
Comment 7 Steve Dickson 2014-02-05 16:41:00 EST
(In reply to J. Bruce Fields from comment #4)
> On a quick glance at git, it looks to me like rhel5 might be missing
> upstream's bdfe0d28ee4c23dec311423a34b2a3ec65b5b318 "Don't always use
> default mapping to "nobody"."  Steved, can you confirm that?
Yes its missing this patch...
Comment 9 Steve Dickson 2014-02-10 10:43:34 EST
(In reply to Steve Dickson from comment #7)
> (In reply to J. Bruce Fields from comment #4)
> > On a quick glance at git, it looks to me like rhel5 might be missing
> > upstream's bdfe0d28ee4c23dec311423a34b2a3ec65b5b318 "Don't always use
> > default mapping to "nobody"."  Steved, can you confirm that?
> Yes its missing this patch...

it turns out that this patch is not the problem... The problem is in
id/gid mapping routines in libnfsidmap. Unfortunately there is not 
RHEL5 libnfsidmap git tree... So debugging this, at this point, is 
not possible.

Plus the v4 support in RHEL5 is iffy at best. So i would suggest to
move back to v3 or used the v4 in RHEL6.

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