Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 274412 - net-fs/nfs-utils: nfs resets sticky bit when writing to a file that already exists
Summary: net-fs/nfs-utils: nfs resets sticky bit when writing to a file that already e...
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo's Team for Core System packages
Depends on:
Reported: 2009-06-16 21:08 UTC by Sascha Hlusiak
Modified: 2021-08-19 19:14 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---

simple test code (test.c,593 bytes, text/plain)
2009-09-09 07:43 UTC, SpanKY

Note You need to log in before you can comment on or make changes to this bug.
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?


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.