site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Hi, Thanks for the reply.. -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... On Apr 22, 2009, at 4:03 AM, Singh, Gangadhar S (BIO) wrote: 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. This email sent to site_archiver@lists.apple.com