On Sun, Jan 15, 2017 at 1:04 AM, Casey Schaufler <ca...@schaufler-ca.com> wrote: > On 1/14/2017 6:15 AM, sf...@users.sourceforge.net wrote: >> Arun Chandran: > > Thank you for using Smack! > >>> # mount -t aufs -o br=./layer2=rw:./layer1=ro:./layer0=ro -o >>> udba=reval -o noplink,smackfsdef=k1,smackfsroot=k1 none ./rootfs_mnt > > The smackfsdef option specifies the Smack label to use if > there is no security.SMACK64 xattr available for an object > on the filesystem. Note that the active Smack label on an > object is stored in the inode, so if an object is created > on any filesystem it will get the Smack label of the creating > process*. If the filesystem does not support xattrs the Smack > label will be lost on reboot. > >> 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. > > I'm not well versed in aufs, but if it's like cryptfs or > overlayfs some of the details of how xattrs are maintained > may be mode complicated than they might seem. With that > caution in mind, your description above ought to hold. > >> 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? > > Assuming all the mechanics are in order that is > what I would expect. >
Thanks for the nice explanation. so 'smackfsdef' for files that don't have support to store label. In my case I have all the branches(layers) and files labelled as 'k1' and the underlying filesystem(ext4) supports the extended attributes. Please see the files and their attributes below. ---------------------------------------------- # for i in `find layer*`; do chsmack $i; done layer0 access="k1" layer0/0.txt access="k1" layer1 access="k1" layer1/1.txt access="k1" # # chsmack rootfs_mnt/ rootfs_mnt/ access="k1" # pwd /home/test # cat /proc/self/attr/current k1 # chsmack . . access="k1" # # id uid=1001(test) gid=1001(test) groups=1001(test) # ---------------------------------------------------- All I want is to do aufs mount layer0 and layer1 and perform normal filesytem operations there. Now I mount the layers. As I can't mount as user test, I execute the mount in a root terminal # mount -t aufs -o br=./layer1=rw:./layer0=ro -o udba=reval none -o smackfsroot=k1 ./rootfs_mnt # id uid=0(root) gid=0(root) groups=0(root),10(wheel) When I try to delete the files as a user test # cd rootfs_mnt/ # ls 0.txt 1.txt # rm * rm: can't remove '0.txt': Permission denied # # ls 0.txt This happens because aufs handles removal of files through newly created file "layer1/.wh..wh.aufs"(I am guessing this from the below printk), as this file got created during the mount operation it is labeled as "_" [ 3365.600800] audit: type=1400 audit(1484470779.482:23): lsm=SMACK fn=smack_inode_link action=denied subject="k1" object="_" requested=w pid=385 comm="rm" name=".wh..wh.aufs" dev="hda1" ino=796 In short words, what I am looking is a mount option like this "aufs_meta_files_def_smack_label=k1" :). Could you please give me pointer to how to implement such an option? --Arun ------------------------------------------------------------------------------ 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
