Bug 830947 - chown doesn't work on nfsv4 mounted directory
Summary: chown doesn't work on nfsv4 mounted directory
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: nfs-utils
Version: 5.8
Hardware: i686
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Steve Dickson
QA Contact: Filesystem QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-06-11 18:22 UTC by Thomas Cameron
Modified: 2014-02-10 15:43 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-02-10 15:43:34 UTC
Target Upstream Version:
Embargoed:


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

Description Thomas Cameron 2012-06-11 18:22:58 UTC
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 18:26:46 UTC
Created attachment 590992 [details]
wireshark dump

Comment 2 Thomas Cameron 2012-06-11 18:27:34 UTC
Created attachment 590993 [details]
sosreport for Fedora 17 client

Comment 3 Thomas Cameron 2012-06-11 18:58:48 UTC
Created attachment 590998 [details]
sosreport from rhel5 server

Comment 4 J. Bruce Fields 2012-06-14 20:21:03 UTC
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 13:37:09 UTC
perhaps related: chown() on NFS4 does not work in Fedora 17 because wrong domain is used. bug #829362

Comment 6 RHEL Program Management 2014-01-29 10:36:37 UTC
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 21:41:00 UTC
(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 15:43:34 UTC
(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.