Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 274412

Summary: net-fs/nfs-utils: nfs resets sticky bit when writing to a file that already exists
Product: Gentoo Linux Reporter: Sascha Hlusiak <bugs>
Component: [OLD] Core systemAssignee: Gentoo's Team for Core System packages <base-system>
Status: CONFIRMED ---    
Severity: normal CC: myk002, vapier
Priority: High    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Attachments: simple test code

Description Sascha Hlusiak 2009-06-16 21:08:19 UTC
Example usecase, inside a nfs3 mounted volume:
# cp /bin/ls /somenfsmount/ls
# chmod 4540 /somenfsmount/ls
 (/somenfsmount/ls does have 4540 now)
# strip /somenfsmount/ls
 (/somenfsmount/ls has 0540 now!)

This only seems to happen on NFS mounted volumes if the user has no write (ugo-w) access to the file to strip. root can strip anyway, but the sticky bits are  reset unless the file is writable. 

7555 -> 1555
but 7755 -> 7755
and 7311 -> 7311

This effectively is a showstopper for using emerge on nfs root, when binaries are u-w for root like wireshark (/usr/bin/dumpcap, 6550) or virtualbox-bin.

This problem seems to be closely related to NFS and to strip but while I don't know the expected behaviour it might as well just being portage that should strip binaries _before_ calling fperms?


sys-devel/binutils-2.19.1-r1
sys-apps/portage-2.2_rc33


Reproducible: Always

Steps to Reproduce:
Comment 1 SpanKY gentoo-dev 2009-09-09 07:42:24 UTC
not specific to binutils/strip in any way.  nfs itself is resetting these perms.

simple test code shows the differences between ext3 and nfs mounts

$ ./a.out /mnt/ext3/foo
/mnt/ext3/foo does not exist
mode of /mnt/ext3/foo: 104540
mode of /mnt/ext3/foo: 104540

$ ./a.out /mnt/nfs/foo
/mnt/nfs/foo does not exist
mode of /mnt/nfs/foo: 104540
mode of /mnt/nfs/foo: 100540
Comment 2 SpanKY gentoo-dev 2009-09-09 07:43:01 UTC
Created attachment 203561 [details]
simple test code
Comment 3 Sascha Hlusiak 2009-09-09 20:25:00 UTC
Wow, that is interesting, thanks for breaking that down.
Do you know if that is a feature or a bug? NFSv4 does not seem to have this issue but rootfs on NFSv4 is not supported. Doesn't that affect all thinclient installations using nfsroot?
Comment 4 Myk Taylor 2012-06-20 02:53:12 UTC
I work around this issue by adding nostrip to FEATURES, but it isn't an ideal solution.