I asked a while back if there was any utility function to evaluate a ZFS
ACL, I didn''t get much of a response and was unable to find anything,
so
decided to implement my own C code.
It appears the acl_get() function is a convenient way to read the ACL;
however, I don''t see an efficient way to parse the data structure
returned.
The function returns an "acl_t *", which is defined in
<sys/acl.h> as
"typedef struct acl_info acl_t;"
The acl_info struct does not appear to be defined in any header files
shipped with Solaris 10. Browsing the opensolaris code base, I found the
definition in <sys/acl_impl.h> to be:
struct acl_info {
acl_type_t acl_type; /* style of acl */
int acl_cnt; /* number of acl entries */
int acl_entry_size; /* sizeof acl entry */
int acl_flags; /* special flags about acl */
void *acl_aclp; /* the acl */
};
Is the acl_t intentionally designed to be opaque? It seems the only thing I
can do with it is pass it to acltotext(), which will return a text string
describing the ACL.
It doesn''t seem particularly efficient to pass a C structure to a
function
that converts it to a string, and then use C code to parse the text string.
I would prefer to directly access the acl_info structure.
On the other hand, it appears all of the information necessary to use the
acl(2) system call is present with Solaris 10. However, that is a rather
raw and basic interface to the ACL, requiring some extra code wrapped
around it to make it useful.
The exact same code that''s probably in acl_get(), and it seems
redundant to
duplicate it.
So either I use the raw underlying system call, which is less than
desirable, or I use acl_get() but have to perform text parsing, which is
less than desirable.
I think I''m inclined to simply copy the data structure definition from
<sys/acl_impl.h> into my code so I can access the acl_t directly, which
probably isn''t recommended and will no doubt break if the internal
implementation changes; but it seems the effort to fix it when it breaks
would be less than either the effort to use the underlying system call or
the effort to parse the text.
Unless I''m missing something? Thanks for any feedback...
--
Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst | henson at csupomona.edu
California State Polytechnic University | Pomona CA 91768
Paul B. Henson wrote:> I asked a while back if there was any utility function to evaluate a ZFS > ACL, I didn''t get much of a response and was unable to find anything, so > decided to implement my own C code. > > It appears the acl_get() function is a convenient way to read the ACL; > however, I don''t see an efficient way to parse the data structure returned. > > The function returns an "acl_t *", which is defined in <sys/acl.h> as > "typedef struct acl_info acl_t;" > > The acl_info struct does not appear to be defined in any header files > shipped with Solaris 10. Browsing the opensolaris code base, I found the > definition in <sys/acl_impl.h> to be: > > struct acl_info { > acl_type_t acl_type; /* style of acl */ > int acl_cnt; /* number of acl entries */ > int acl_entry_size; /* sizeof acl entry */ > int acl_flags; /* special flags about acl */ > void *acl_aclp; /* the acl */ > }; > > Is the acl_t intentionally designed to be opaque?Yes, its meant to be opaque. The layout of the acl_t will likely change in the not too distant future.> can do with it is pass it to acltotext(), which will return a text string > describing the ACL. > > It doesn''t seem particularly efficient to pass a C structure to a function > that converts it to a string, and then use C code to parse the text string. > > I would prefer to directly access the acl_info structure. >There are a number of private interfaces in libsec to retrieve stuff out of the ACL, but they aren''t documented interfaces, such as acl_data() which will return you the pointer to the array of ace_t''s and acl_cnt() that will return you the number of ACEs in the array. With those two interfaces you can then easily iterate over the ACL.> So either I use the raw underlying system call, which is less than > desirable, or I use acl_get() but have to perform text parsing, which is > less than desirable. > > I think I''m inclined to simply copy the data structure definition from > <sys/acl_impl.h> into my code so I can access the acl_t directly, which > probably isn''t recommended and will no doubt break if the internal > implementation changes; but it seems the effort to fix it when it breaks > would be less than either the effort to use the underlying system call or > the effort to parse the text. > > Unless I''m missing something? Thanks for any feedback... > >We are currently investigating adding more functionality to libsec to provide many of the things you desire. We will have iterators, editing capabilities and so on. -Mark
Is the acl_t intentionally designed to be opaque? Yes, its meant to be opaque. The layout of the acl_t will likely change in the not too distant future. Will old versions be supported? For example, if ADM treats it as opaque and archives the current format, after an upgrade (layout change), could we write the old ACL to the new ZFS code? thanks, Joe _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
On Fri, 15 Aug 2008, Mark Shellenbaum wrote:> The layout of the acl_t will likely change in the not too distant future.[...]> of the ACL, but they aren''t documented interfaces, such as acl_data() > which will return you the pointer to the array of ace_t''s and acl_cnt() > that will return you the number of ACEs in the array. With those two > interfaces you can then easily iterate over the ACL.Ah, thanks for the pointer. Reviewing the libsec code, I see there is also acl_type(), and acl_flags(), but I don''t see anything for accessing the acl_entry_size. However, both aclent_t and ace_t are publicly documented so sizeof() should do the trick. Are the libsec undocumented interfaces likely to remain the same when the acl_t structure changes? They will still require adding the prototypes to my code so the compiler knows what to make of them, but less chance of breakage is good.> We are currently investigating adding more functionality to libsec to > provide many of the things you desire. We will have iterators, editing > capabilities and so on.Sweet. Might I request an acl evaluation function? Which basically, given a user and a requested permission, returns either true (user has permission), false (user doesn''t have permission), or error condition. Similar to the POSIX access() call, but for ACLs. If I had that I wouldn''t need to be mucking around with the ACL directly at all :), as that''s basically what I''m implementing... Thanks much, I always appreciate your informative responses. -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | henson at csupomona.edu California State Polytechnic University | Pomona CA 91768
On Fri, 15 Aug 2008, Paul B. Henson wrote:> Ah, thanks for the pointer. Reviewing the libsec code, I see there is also > acl_type()Looks like the acl_type_t enum isn''t in the public headers either though. But presumably that''s not likely to change... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | henson at csupomona.edu California State Polytechnic University | Pomona CA 91768
Joe Blount wrote:> >>> Is the acl_t intentionally designed to be opaque? >>> >> >> Yes, its meant to be opaque. >> >> The layout of the acl_t will likely change in the not too distant future. >> > > Will old versions be supported? For example, if ADM > <http://www.opensolaris.org/os/project/adm/> treats it as opaque and > archives the current format, after an upgrade (layout change), could we > write the old ACL to the new ZFS code? > > thanks, > Joeacl_t is a purely in-core data structure, and is not appropriate for storing in an archive. Thats what interfaces such as acl_totext() are for. ADM should be archiving the ACL in a textual representation, much like tar/cpio do. The interfaces such as acl_get()/acl_set() are merely convenience functions to make it easier for getting/setting ACLs without having to know if the file system is ZFS or UFS. For example acl_get() knows how to determine if a file system supports POSIX draft ACLs or NFSv4 ACL and then uses the native acl(2) syscall to retrieve the data. -Mark
Paul B. Henson wrote:> On Fri, 15 Aug 2008, Mark Shellenbaum wrote: > >> The layout of the acl_t will likely change in the not too distant future. > [...] >> of the ACL, but they aren''t documented interfaces, such as acl_data() >> which will return you the pointer to the array of ace_t''s and acl_cnt() >> that will return you the number of ACEs in the array. With those two >> interfaces you can then easily iterate over the ACL. > > Ah, thanks for the pointer. Reviewing the libsec code, I see there is also > acl_type(), and acl_flags(), but I don''t see anything for accessing the > acl_entry_size. However, both aclent_t and ace_t are publicly documented so > sizeof() should do the trick. > > Are the libsec undocumented interfaces likely to remain the same when the > acl_t structure changes? They will still require adding the prototypes to > my code so the compiler knows what to make of them, but less chance of > breakage is good. >I can''t guarantee they will remain in the future. Thats why they aren''t documented. It may be that with appropriate iterators and other interfaces they will no longer be needed.>> We are currently investigating adding more functionality to libsec to >> provide many of the things you desire. We will have iterators, editing >> capabilities and so on. > > Sweet. Might I request an acl evaluation function? Which basically, given a > user and a requested permission, returns either true (user has permission), > false (user doesn''t have permission), or error condition. Similar to the > POSIX access() call, but for ACLs. If I had that I wouldn''t need to be > mucking around with the ACL directly at all :), as that''s basically what > I''m implementing... > > Thanks much, I always appreciate your informative responses.Yep, the evaluation sort of thing is on our list of things to look into. -Mark
Mark Shellenbaum wrote:> Paul B. Henson wrote: >> >> Are the libsec undocumented interfaces likely to remain the same when the >> acl_t structure changes? They will still require adding the prototypes to >> my code so the compiler knows what to make of them, but less chance of >> breakage is good. >> >> > > I can''t guarantee they will remain in the future. Thats why they aren''t > documented. > > It may be that with appropriate iterators and other interfaces they will > no longer be needed. > >I''m working on a similar problem to Paul (sorry I didn''t get back to you Paul - shifting priorities!), writing a PHP extension for ACLs, and I''ve fallen into the trap of using acl_info. Is this work you mention happening in the open, or in side of Sun? If it''s the former, how can we get involved? Ian
Paul B. Henson wrote:> Sweet. Might I request an acl evaluation function? Which basically, given a > user and a requested permission, returns either true (user has permission), > false (user doesn''t have permission), or error condition. Similar to the > POSIX access() call, but for ACLs. If I had that I wouldn''t need to be > mucking around with the ACL directly at all :), as that''s basically what > I''m implementing...You need to understand though that access(2) and any equivalent function that evaluates an ACL is NOT authoritative. The only way to get an authoratative answer is to actually try the operation. In privileged programs you must be careful that you do not introduce "Time Of Check To Time Of Use" security vulnerabilities when using functions like access(2). Only the kernel should make the access control decision and use of functions like access(2) should generally only be used to assist in providing a more informative error message. The reason for this is is that it is not just the evaluation of the ACL/permission as that user that determines the final result. Other things can impact it as well - for example the Trusted Extensions mandatory access label (ie a zone) and in the future the FMAC[1] security context. As long as you take that into account a function to evaluate access control can be used safely. [1] http://opensolaris.org/os/project/fmac/ -- Darren J Moffat
Ian Collins wrote:> Mark Shellenbaum wrote: >> Paul B. Henson wrote: >>> Are the libsec undocumented interfaces likely to remain the same when the >>> acl_t structure changes? They will still require adding the prototypes to >>> my code so the compiler knows what to make of them, but less chance of >>> breakage is good. >>> >>> >> I can''t guarantee they will remain in the future. Thats why they aren''t >> documented. >> >> It may be that with appropriate iterators and other interfaces they will >> no longer be needed. >> >> > I''m working on a similar problem to Paul (sorry I didn''t get back to you > Paul - shifting priorities!), writing a PHP extension for ACLs, and I''ve > fallen into the trap of using acl_info. Is this work you mention > happening in the open, or in side of Sun? If it''s the former, how can > we get involved? > > IanCurrently we are just doing some preliminary discussions internal to Sun? Were you looking to help out and provide some code? We could probably include you in the discussions if you are interested. -Mark
Mark Shellenbaum wrote:> Ian Collins wrote: >> Mark Shellenbaum wrote: >>> Paul B. Henson wrote: >>>> Are the libsec undocumented interfaces likely to remain the same >>>> when the >>>> acl_t structure changes? They will still require adding the >>>> prototypes to >>>> my code so the compiler knows what to make of them, but less chance of >>>> breakage is good. >>>> >>>> >>> I can''t guarantee they will remain in the future. Thats why they >>> aren''t documented. >>> >>> It may be that with appropriate iterators and other interfaces they >>> will no longer be needed. >>> >>> >> I''m working on a similar problem to Paul (sorry I didn''t get back to you >> Paul - shifting priorities!), writing a PHP extension for ACLs, and I''ve >> fallen into the trap of using acl_info. Is this work you mention >> happening in the open, or in side of Sun? If it''s the former, how can >> we get involved? >> >> Ian > > Currently we are just doing some preliminary discussions internal to > Sun? Were you looking to help out and provide some code? We could > probably include you in the discussions if you are interested. >I''ve been doing quite a bit of work on the user side of the fence recently, so yes I would be interesting in contributing. Ian
Mark Shellenbaum wrote:> Joe Blount wrote: >> >>>> Is the acl_t intentionally designed to be opaque? >>>> >>> >>> Yes, its meant to be opaque. >>> >>> The layout of the acl_t will likely change in the not too distant >>> future. >>> >> >> Will old versions be supported? For example, if ADM >> <http://www.opensolaris.org/os/project/adm/> treats it as opaque and >> archives the current format, after an upgrade (layout change), could >> we write the old ACL to the new ZFS code? >> >> thanks, >> Joe > > acl_t is a purely in-core data structure, and is not appropriate for > storing in an archive. Thats what interfaces such as acl_totext() are > for. ADM should be archiving the ACL in a textual representation, > much like tar/cpio do.We''re trying to use DMAPI interfaces for all interaction with the filesystem. The DMAPI interfaces take a DMAPI handle (fsid & fid), and call the DMAPI kernel driver which uses the handle to get a vnode and do whatever was requested... I was hoping to add a DMAPI ACL interface like this - in the kernel get the ACL for a vnode (VOP_GETSECATTR), and convert it to text... Is there an acl to text interface available in the kernel? thanks, Joe> > The interfaces such as acl_get()/acl_set() are merely convenience > functions to make it easier for getting/setting ACLs without having to > know if the file system is ZFS or UFS. For example acl_get() knows > how to determine if a file system supports POSIX draft ACLs or NFSv4 > ACL and then uses the native acl(2) syscall to retrieve the data. > > > -Mark
Joe Blount wrote:> Mark Shellenbaum wrote: >> Joe Blount wrote: >>>>> Is the acl_t intentionally designed to be opaque? >>>>> >>>> Yes, its meant to be opaque. >>>> >>>> The layout of the acl_t will likely change in the not too distant >>>> future. >>>> >>> Will old versions be supported? For example, if ADM >>> <http://www.opensolaris.org/os/project/adm/> treats it as opaque and >>> archives the current format, after an upgrade (layout change), could >>> we write the old ACL to the new ZFS code? >>> >>> thanks, >>> Joe >> acl_t is a purely in-core data structure, and is not appropriate for >> storing in an archive. Thats what interfaces such as acl_totext() are >> for. ADM should be archiving the ACL in a textual representation, >> much like tar/cpio do. > We''re trying to use DMAPI interfaces for all interaction with the > filesystem. The DMAPI interfaces take a DMAPI handle (fsid & fid), and > call the DMAPI kernel driver which uses the handle to get a vnode and do > whatever was requested... > I was hoping to add a DMAPI ACL interface like this - in the kernel get > the ACL for a vnode (VOP_GETSECATTR), and convert it to text... Is > there an acl to text interface available in the kernel? >the functions to convert an ACL to/from text aren''t available in the kernel. You would only want to archive a non-trivial ACL and you can use fs_acl_nontrivial() in the kernel to determine that. -Mark
On Fri, Aug 15, 2008 at 08:15:56PM -0600, Mark Shellenbaum wrote:> We are currently investigating adding more functionality to libsec to > provide many of the things you desire. We will have iterators, editing > capabilities and so on.I''m still ironing a design/architecture document out. I''ll share it with Paul (and maybe the list?) when it''s ready. Nico --
Nicolas Williams wrote:> On Fri, Aug 15, 2008 at 08:15:56PM -0600, Mark Shellenbaum wrote: > >> We are currently investigating adding more functionality to libsec to >> provide many of the things you desire. We will have iterators, editing >> capabilities and so on. >> > > I''m still ironing a design/architecture document out. I''ll share it > with Paul (and maybe the list?) when it''s ready. > >Please do, I''ve been working with the features Mark mentions using a C++ wrapper around the libsec interfaces. This code should provide enough decoupling to cope with library interface changes. Ian