sf...@users.sourceforge.net: > > Torsten Luettgert: > > I don't understand yet why you would collect XATTRs from lower > > branches, too. In directories, it's clear, because it's not logical > > if you can see only part of the contents (from the branches which > > allow access to the directory). The only thing I can imagine is > > something like > > Thanks for the comments. > After my posting, I changed my mind and the result is same to your > thinking (my reason is different from yours, though). > Here is the updated version, but it is still draft. > I hope we could reach the aggrement about list/get at least. > > Also I am thinking to change "cpea_sec" to "cpxsec", because it is > shorter.
This approach is "user chooses the category of XATTR to copy-up" basically. I have another idea which is "user chooses XATTR to ignore the error in copy-up." In other words, the former makes aufs to copy-up the specified XATTR only, but the latter is makes aufs tries copying-up all XATTR. Here is an updated doc. If you (or anyone) have any comment, please let me know. J. R. Okajima Listing XATTR/EA and getting the value ---------------------------------------------------------------------- For the inode standard attributes (owner, group, timestamps, etc.), aufs shows the values from the topmost existing file. This behaviour is good for the non-dir entreis since the bahaviour exactly matches the shown information. But for the directories, aufs considers all the same named entries on the lower branches. Which means, if one of the lower entry rejects readdir call, then aufs returns an error even if the topmost entry allows it. This behaviour is necessary to respect the branch fs's security, but can make users confused since the user-visible standard attributes don't match the behaviour. To address this issue, aufs has a mount option called dirperm1 which checks the permission for the topmost entry only, and ignores the lower entry's permission. A similar issue can happen around XATTR. getxattr(2) and listxattr(2) families behave as if dirperm1 option is always set. Otherwise these very unpleasant situation can happen. - listxattr(2) may return the duplicated entires. - users may not be able to remove or reset the XATTR forever, XATTR/EA support in the internal (copy,move)-(up,down) ---------------------------------------------------------------------- Generally the extended attributes of inode are categorazied as these. - "security" for LSM and capability. - "system" for posix ACL, 'acl' mount option is required for the branch fs generally. - "trusted" for userspace, CAP_SYS_ADMIN is required. - "user" for userspace, 'user_xattr' mount option is required for the branch fs generally. Moreover there are some other categories. Aufs handles these rather unpopular categories as the ordinary ones, ie. there is no special condition nor exception. In the copy-up operation, aufs should copy *all* the attibutes from the source branch fs to the destination branch fs. But the support for XATTR on the dst branch may differ from the src branch. In this case, the copy-up operation will get an error and the original user operation which triggered the copy-up fails. It can happen that even all copy-up will fail. When both of src and dst branches support XATTR and if an error occurs during copying XATTR, then the copy-up should fail obviously. That is a good reason and aufs should return an error to userspace. But when only the src branch support XATTR, aufs should not return an error. For example, the src branch supports ACL but the dst branch doesn't because the dst branch may natively un-support it or temporary un-support it due to "noacl" mount option. Of course, the dst branch fs may NOT return an error even if the XATTR is not supported. It is totally up to the branch fs. Anyway when the aufs internal copy-up gets an error from the dst branch fs, then aufs tries removing the just copied entry and returns the error to the userspace. The worst case of this situation will be all copy-up will fail. In order to support XATTR and to implement the correct behaviour, new attributes are introduced for aufs writable branches, "ixsec", "ixsys", "ixtr", "ixusr", and "ixoth". They correspond to the XATTR namespaces (see above). Additionally, to be convenient, "ix" is also provided which means all "ix*" attributes are set. The meaning of these attributes is to ignore the error from setting XATTR on that branch. Note that aufs tries copying all XATTR unconditionally, and ignores the error from the dst branch according to the specified attributes. Some XATTR may have its default value. The default value may come from the parent dir or the environment. If the default value is set at the file creating-time, it will be overwritten by copy-up. Hmm, some contradiction may happen I am afraid. Do we need another attribute to stop copying XATTR? I am unsure. For now, aufs implements the branch attributes to ignore the error. ------------------------------------------------------------------------------ Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
