Arun Chandran: > # mount -t aufs -o br=./layer2=rw:./layer1=ro:./layer0=ro -o > udba=reval -o noplink,smackfsdef=k1,smackfsroot=k1 none ./rootfs_mnt
I'd suggest you to specify and test smack options on layerN instead of rootfs_mnt. Aufs is a virtual filesystem and it doesn't have a backend block device. Which means it doesn't store smack attributes to the disk. All attributes are handled and stored by the branch fs (layner[0-2] in your case). > # chsmack rootfs_mnt/ > rootfs_mnt/ access="k1" So this k1 value is taken from the topmost branch (./layer2 in your case). Here is what I am thinking/guessing, - smack mount options try setting the default attribute to rootfs_mnt, which will be applied to all files under rootfs_mnt. - rootfs_mnt is aufs, I mean "virtual". - all attributes in aufs are inherited from the branch fs. - even if you and smack set attribute to virtual aufs, it will be overwritten by the real one on the branch fs. Again I'd suggest you to set smack options to your branches instead of aufs. Let's consider a further case. - /u = /rw + /ro - specify smackfsdef=privA to /rw - specify smackfsdef=privB to /u and then case1: access /rw/fileC as smack privA case2: access /rw/fileC as smack privB case3: access /u/fileC as smack privA case4: access /u/fileC as smack privB case1 shoule be allowed obviously. case2 will be rejected, since /rw accepts privA only. case3, to be or not to be? That is the question. If we follow a principle that /u accepts privB only, then case3 should be rejected. But internally this behaviour concludes an access to /rw/fileC. As long as /rw accepts privA, case3 should be allowed based upon /rw's point of view. case4 is just a counter of case3. As a very fundamental design, aufs tries behaving as the branch fs would do (as possible). All accesses go to the branches, and all data is retrived from the branches. So my (current) conclusion is - setting smackfsdef to aufs has no meaning. - the effective smack attribute is the one set to the branch fs. How do you think? J. R. Okajima ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi
