Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com From: ericblake AT comcast DOT net (Eric Blake) To: cygwin AT cygwin DOT com Subject: NFS mounts and chmod directory Date: Thu, 14 Apr 2005 18:08:48 +0000 Message-Id: <041420051808.24301.425EB1AF000B9AA500005EED22069997350A050E040D0C079D0A@comcast.net> X-Authenticated-Sender: ZXJpY2JsYWtlQGNvbWNhc3QubmV0 So, is the following terminal trace just due to the braindead NFS implementation of Win2000 SP4, or is there a bug in cygwin chmod(2) in regards to directory permissions? I have /cygdrive/u viewing my home drive on a unix box NFS server named perth. $ cd /cygdrive/u $ alias ll='ls -lF' $ umask 0022 $ mkdir dir $ ll -d dir drwxr-xr-x 1 eblake Domain Users 0 Apr 14 11:35 dir/ $ ssh perth ll -d dir eblake AT perth's password: drwxrwsr-x 2 eblake eblake 4096 Apr 14 11:35 dir/ $ # Hmm, how come the sticky bit is set, and it is group readable on Unix? $ chmod 0 dir $ ll -d dir dr-xr-xr-x 1 eblake Domain Users 0 Apr 14 11:37 dir/ $ # Hmm, why can I still read and search? Also, Windows claims not writable... $ ssh perth ll -d dir eblake AT perth's password: drwxr-sr-x 2 eblake eblake 4096 Apr 14 11:37 dir/ $ # ...but Unix says it is. All that changed was group write. $ ll -d dir drwxr-xr-x 1 eblake Domain Users 0 Apr 14 11:37 dir/ $ # Whoa - now Windows agress it is writable $ chmod 777 dir $ ll -d dir drwxr-xr-x 1 eblake Domain Users 0 Apr 14 11:37 dir/ $ # Hmm, Windows thinks it is still not group or other writable... $ ssh perth ll -d dir eblake AT perth's password: drwxrwsr-x 2 eblake eblake 4096 Apr 14 11:37 dir/ $ # ...but Unix says it is just not other writable $ ssh perth chmod 777 dir $ ll -d dir drwxr-xr-x 1 eblake Domain Users 0 Apr 14 11:42 dir/ $ # Nope, Windows still can't see group and other writable... $ ssh perth ll -d dir eblake AT perth's password: drwxrwsrwx 2 eblake eblake 4096 Apr 14 11:42 dir/ $ # ...even though Unix just set it that way $ ssh perth chmod 0 dir eblake AT perth's password: $ ll -d dir drwxr-xr-x 1 eblake Domain Users 0 Apr 14 11:42 dir/ $ test -w dir && echo yes || echo no yes $ # Hey, Windows is pretty generous now, it is still writable... $ ssh perth ll -d dir eblake AT perth's password: d-----l--- 2 eblake eblake 4096 Apr 14 11:42 dir/ $ ssh perth \$HOME/bin/ls -lF -d dir eblake AT perth's password: d-----S--- 2 eblake eblake 4096 Apr 14 11:42 dir/ $ # ...while Unix has stripped all permissions (l vs. S is Solaris vs. GNU spelling of sticky bit without search permission) $ touch dir/file touch: cannot touch `dir/file': Permission denied $ ll -d dir dr-xr-xr-x 1 eblake Domain Users 0 Apr 14 11:42 dir/ $ test -w dir && echo yes || echo no no $ # Well, at least NOW Windows no longer claims it is writable, but it took an attempted write to find that out. And what's up with read and search perms? I found this when running the coreutils testsuite. Needless to say, weird things happened when the testsuite did chmod a-w, but the directory was still writable. I don't know if it is a) possible, or b) sensible to make chmod(2) fail if it couldn't do exactly what it was asked on NFS-mounted directories. -- Eric Blake -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/