I posted a question about this last month. Sorry it's taken so
long to send the summary, which I'll present as a FAQ question. This
will also appear soon (try next week) on a Solaris 2 Migration FAQ
that will be at:
http://www.sun.com/smcc/solaris-migration/docs/faq/faq.html
You might also look at Bug Report #1178641 for a discussion of some
of these issues, particularly why mandatory file locking is not
supported over NFS.
Thanks to all those who helped with this...
+----------------------------------------------------------------+
Q: I have some files on an NFS server that I have not been able to read
since I upgraded to Solaris 2.x. The files have the "l" permission bit
set, as in the following:
-rw-r-lr-- 1 me mygroup 0 Nov 11 11:11 myfile
What does the "l" mean, and why can't I read the files?
A: In SVR4, there is a mode called "mandatory file locking" which is
represented by an "l" in the group execute field. This mode is not
supported over NFS, and so such files are by default unreadable and
unwriteable on NFS clients. Unlike most permissions, mandatory file
locking is enabled by a combination of two bits. The set-group-id bit
is set and the group execute bit is cleared. If all other bits are
cleared, this appears as symbolic mode 2000.
On BSD-derived systems such as SunOS 4.x, this same combination of
bits has no meaning, and appears in ls -l output as an uppercase S
in the group execute field, for instance:
-rw-r-Sr-- 1 me 0 Jan 1 00:01 myfile
Note that normally a file intended to have set-group-id behavior is
an executable file, and so both bits are set and a lowercase s is used,
for instance:
-rwxr-sr-x 1 me 0 Jan 1 00:01 myfile
Such a mode might be set inadvertently if a non-executable file were
in a directory tree that had a recursive chmod g+s applied to it:
host% ls -ld mydir
-rwxr-xr-x 1 me 0 Jan 1 00:01 mydir
host% ls -l mydir
-rw-r--r-- 1 me 0 Jan 1 00:01 myfile
host% chmod -R g+s mydir
host% ls -ld mydir
-rwxr-sr-x 1 me 0 Jan 1 00:01 mydir
host% ls -l mydir
-rw-r-Sr-- 1 me 0 Jan 1 00:01 myfile
When this same file is viewed on a Solaris 2.x system, the "S" becomes
an "l", and if on an NFS file system, is unreadable. You can apply a
"chmod g-l" to fix the problem if you have write access to the file.
Otherwise, you'll have to find someone that does.
Also note that Solaris 2.x will attempt to prevent you from setting
mandatory file locking inadvertently. Any attempt to chmod g+s on a
non-executable file will generate an error:
chmod: WARNING: Execute permission required for set-ID on execution for myfile
Instead, you must explicitly specify "g+l", or use symbolic mode.
+------------------------------------------------------------------+
Rob Wood UNIX Software Consultant
Taos Mountain Softare, Inc. robwood@netcom.com
+------------------------------------------------------------------+
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:29 CDT