[Summary] ufs acl puzzle
Chris Hoogendyk <[email protected]>
| Newsgroups | gmane.os.solaris.managers |
|---|---|
| Message-ID | <[email protected]> |
Wow. I just solved this puzzle. Thought I would pass it along in case anyone else steps into the
same pothole. The message I had started to compose to ask the list for help is at the end. Here is
the problem and the solution.
I have a few Solaris 10 systems that had been set up with CoolStack and CoolTools on T5220's. Given
the lack of support for these from Oracle, I had decided to set up new build environments using
standard gcc and gnu tools. One of the things I installed (don't ask me why) was the gnu coreutils
package form Sunfreeware (now Unixpackages).
coreutils includes things like ls, mkdir, chmod, etc., and is installed in /usr/local. So,
/usr/local/bin/chmod, etc. These utilities do not understand Solaris ACLs (or at least treat them
"differently"). In any case, I found that people whose PATH has /usr/local/bin before /usr/bin will
get the gnu coreutils versions of these, while those whose PATH has /usr/bin first will get the
Solaris versions. The results differ (obviously).
I eventually found that in trying to fix this directory,
find /modules -type d -exec chmod g+w {} \; <-- did not work
find /modules -type d -exec /bin/chmod g+w {} \; <-- did work
So, if you have a Solaris system, and use ACLs, and have gnu coreutils installed, you could fall
into this pothole. You will have to use explicit paths for executables, and/or sort out your PATH,
and/or decide whether you really want or need coreutils.
============ Original Question I was going to ask ================
One of my users brought this problem to my attention. It makes no sense to me, and I can't figure
out how it happened. If someone could help me understand this, I would appreciate it and would pass
it back to the list.
So, we have a directory structure that is supposed to be more open than the system wide umask. So,
we created the directory 775 with acls that would propagate that within the directory. When you look
at it as root, it looks correct. But it doesn't work; and, when you look at it as an ordinary user,
it is different than what root shows. It hurts my head.
Results from `ls -l` and `getfacl` as user root:
drwxrwsr-x+ 4 jkoech bcrcstaf 512 Feb 24 09:12 modules
# file: modules
# owner: jkoech
# group: bcrcstaf
user::rwx
group::r-x #effective:r-x
mask:rwx
other:r-x
default:user::rwx
default:group::rwx
default:mask:rwx
default:other:r-x
As user chrisho:
drwxrwsr-x+ 4 jkoech bcrcstaf 512 Feb 24 09:12 modules
# file: modules
# owner: jkoech
# group: bcrcstaf
user::rwx
group::r-x #effective:r-x
mask:rwx
other:r-x
default:user::rwx
default:group::rwx
default:mask:rwx
default:other:r-x
As user sbrewer:
drwxr-sr-x+ 4 jkoech bcrcstaf 512 Feb 24 09:12 modules
# file: modules
# owner: jkoech
# group: bcrcstaf
user::rwx
group::r-x #effective:r-x
mask:rwx
other:r-x
default:user::rwx
default:group::rwx
default:mask:rwx
default:other:r-x
--
---------------
Chris Hoogendyk
-
O__ ---- Systems Administrator
c/ /'_ --- Biology& Geology Departments
(*) \(*) -- 140 Morrill Science Center
~~~~~~~~~~ - University of Massachusetts, Amherst
<[email protected]>
---------------
Erdvs 4