Re: ACL API ( acl_copy_ext) and ( acl_copy_int) not available for application!!!
Re: ACL API ( acl_copy_ext) and ( acl_copy_int) not available for application!!!
- Subject: Re: ACL API ( acl_copy_ext) and ( acl_copy_int) not available for application!!!
- From: Terry Lambert <email@hidden>
- Date: Wed, 22 Apr 2009 13:07:52 -0700
On Apr 22, 2009, at 4:03 AM, Singh, Gangadhar S (BIO) wrote:
Hi,
Thanks for the reply..
In Linux, we were using these APIs for processing the data between
user managed space and kernel space. Similar requirement has come up
for Mac OS X.
So basically you are using it as a communications channel between user
space and the kernel. Bad idea.
The internal representation in the kernel is as a filesec_t, and there
are APIs for dealing with that *in the kernel*. In user space, you
are expected to use the user space interfaces for dealing with getting
and setting ACLs. There is no opportunity for using this interface as
a covert channel to pass data in and out of, for example, a third
party FS. If that's what you want to do, you will need to look
elsewhere (such as using fcntl(0 to access through VNOP_IOCTL into the
filesystem).
You are basically not allowed to look into the opaque type information
in user space (for one thing, the filesec_t is an opaque pointer type;
for another, we do not guarantee byte order, endienness, or structure
packing between platforms or between kernel and user space; you
basically get whatever the native volume format is, and for that, you
get whatever the native endienness and packing was on the system it
was created on.
So User Application cannot use this APIs since it is not available
in the man pages right?
Incorrect. Whether or not there is a man page for something, an
exported API is an exported API. However, not all exported API is
useful, and some exported API is not documented, either to deprecate
it or to strongly discourage its use. Anything you did with the
internally formatted information would basically not be portable
between releases or software updates, since you are supposed to treat
the contents as opaque.
If you google the FreeBSD implementation of POSIX 1003.1e, which is
what the OpenBSD, MacOS X, SGI IRIX, Tru64 UNIX (from your own
company), Linux, and other implementations are based upon, you will
see that out of the > 100 first results you get back, absolutely none
of them are code examples trying to use them from user space.
There is a reason for that. It's because of the opaque parts not
having defined accessor/mutator functions usable from user space.
Those are intentionally not defined by most vendors (including Apple)
because there is a problem with integer UID vs. ACL UUID coherency, if
you let user space jam any UUID they want into things.
Specifically, no one has solved the cardinality issue where multiple
UUIDs in multiple directory services end up mapping to the same 32 bit
inter value of a uid_t or gid_t in a normal UNIX credential. This
happens because the people who came up with UUIDs in the first place
ignored a lot of inconvenient problems, such as existing file systems
and backup archives. Effectively, that means that you can't take an
integer value and map it back to a single UUID when you are trying to
put an ACL on something, you basically have to guess, or you have to
set a priority ordering on your directory service.
If you use the read/modify/write paradigm, for example, and explicitly
check for the attribute information after the read before the modify/
write, the interfaces could possibly be useful for backup/restore.
But if you were trying to create one from scratch and then use
acl_copy_int() to intern it for the kernel to see, your code is going
to be broken. It will also be broken if you store and retrieve the
internal data format, and also if you communicate the internal data
format between computers in an effort to replicate contents. The read
step is necessary to ensure that the opaque parts of the data for
which there is no useful user space portion (or API for modification
from user space) is filled out correctly by the kernel.
Which are the appropriate APIs that can be used for exchanging the
ACL data between kernel and user space.
chmodx_np, fchmodx_np, openx_np, accessx_np, getattrlist, setattrlist,
and so on are the appropriate APIs for use in user space ACL
manipulation.
In kernel space, your file system is supposed to implement the VNOPs
that correspond to ACL operations. See our published source code for
various file systems for examples.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden