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 system	Assignee:	Gentoo's Team for Core System packages <base-system>
Status:	RESOLVED CANTFIX
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.