| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <45837A24.9040207@laurelnetworks.com> Date: Fri, 15 Dec 2006 23:46:28 -0500 From: Mike Accetta <maccetta@...relnetworks.com> To: linux-kernel@...r.kernel.org Subject: Change in multiple NFS mount behavior in 2.6.19? After upgrading an NFS client from 2.6.18 to 2.6.19 (and also with 2.6.19.1) we see a change in behavior of multiple NFS mounts against the same server (running 2.4.20 in this case). With 2.6.18 we could mount different pieces of the same remote file system with distinct read-only and read-write attributes at corresponding places on the client. With 2.6.19 if the first mount is read-only, subsequent mounts seem to inherit the read-only status even though not explicitly mounted read-only. If I did the "git bisect" properly, the behavior changed with commit 54ceac4515986030c2502960be620198dd8fe25b and the description of this commit seems like it could indeed have caused this behavior, but perhaps not intentionally. I believe the client is making NFS V2 calls. Also, I am still able to issue a "mount -o remount,rw" on the client to regain read-write capability. Was this a regression or is this now the expected behavior for multiple NFS client mounts in 2.6.19? -- Mike Accetta ECI Telecom Ltd. Data Networking Division (previously Laurel Networks) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists