On Fri, 26 Feb 2010, David Dyer-Bennet wrote:
> I think of using ACLs to extend extra access beyond what the permission
> bits grant. Are you talking about using them to prevent things that the
> permission bits appear to grant? Because so long as they're only
> granting extended access, losing them can't expose anything.
Consider the example of creating a file in a directory which has an
inheritable ACL for new files:
drwx--s--x+ 2 henson csupomona 4 Feb 27 09:21 .
owner@:rwxpdDaARWcC--:-di---:allow
owner@:rwxpdDaARWcC--:------:allow
group@:--x---a-R-c---:-di---:allow
group@:--x---a-R-c---:------:allow
everyone@:--x---a-R-c---:-di---:allow
everyone@:--x---a-R-c---:------:allow
owner@:rwxpdDaARWcC--:f-i---:allow
group@:--------------:f-i---:allow
everyone@:--------------:f-i---:allow
When the ACL is respected, then regardless of the requested creation mode
or the umask, new files will have the following ACL:
-rw-------+ 1 henson csupomona 0 Feb 27 09:26 foo
owner@:rw-pdDaARWcC--:------:allow
group@:--------------:------:allow
everyone@:--------------:------:allow
Now, let's say a legacy application used a requested creation mode of
0644, and the current umask was 022, and the application calculated the
resultant mode and explicitly set it with chmod(0644):
-rw-r--r--+ 1 henson csupomona 0 Feb 27 09:26 foo
owner@:----dDaARWcC--:------:allow
group@:--------------:------:allow
everyone@:--------------:------:allow
owner@:--x-----------:------:deny
owner@:rw-p---A-W-Co-:------:allow
group@:-wxp----------:------:deny
group@:r-------------:------:allow
everyone@:-wxp---A-W-Co-:------:deny
everyone@:r-----a-R-c--s:------:allow
A file which had an explicitly configured inherited ACL to be readable only
by the owner is now world readable. Ouch. On the other hard, in a
hypothetical world where aclmode=ignore existed, the undesired chmod would
have been ignored, and the security of the file would not have been
compromised.
> (It can still be tremendously inconvenient, of course;
End users don't like inconvenience :). When their configured access control
is broken, they call the help desk and scream a lot. Being able to
configure an environment which works for their needs would be very
valuable.
> I'm serious about not seeing how it'd be possible to write new
> applications for this environment.
I think we're just going to have to agree to disagree on this one.
> Is there any way for a a bash script to replicate permissions in an ACL
> environment? A Perl app? A C app? Especially one that's trying to be
> POSIX-portable?
A script or application would work with ACL's the exactly same way they
work with any other API, whether it be via calling command line tools, or
using native code to manipulate them.
I'm not saying it's the best way to do it, but off the top of my head
here's bash code to copy an ACL on Solaris:
-rw-r--r--+ 1 henson csupomona 0 Feb 27 09:38 bar
owner@:rw-pdDaARWcC--:------:allow
group@:r-----a-R-c---:------:allow
everyone@:r-----a-R-c---:------:allow
group:cppweb:r-x---a-R-c---:------:allow
-rw-------+ 1 henson csupomona 0 Feb 27 09:38 foo
owner@:rw-pdDaARWcC--:------:allow
group@:--------------:------:allow
everyone@:--------------:------:allow
$ chmod A=`ls -V bar | tail +2 | sed -e 's/^ *//' | tr '\n' ,` foo
-rw-r--r--+ 1 henson csupomona 0 Feb 27 09:38 foo
owner@:rw-pdDaARWcC--:------:allow
group@:r-----a-R-c---:------:allow
everyone@:r-----a-R-c---:------:allow
group:cppweb:r-x---a-R-c---:------:allow
For C apps, man -s 2 acl.
For perl apps, they can either go the bash route of calling out to OS
commands; or if there isn't already a zfs acl module for perl allowing you
to manipulate them directly from perl, I'd write one (like I did for DFS
ACL's back in the day --
http://www.csupomona.edu/~henson/archive/projects/DFS-Perl/)
--
Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst | hen...@csupomona.edu
California State Polytechnic University | Pomona CA 91768
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
