On Mon, Jan 16, 2017 at 1:19 AM, <sf...@users.sourceforge.net> wrote: > > Arun Chandran: >> --------------------------------------------- >> Files in the layers before mounting >> ---------------------------------------------- >> # 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" > > At this point, won't you try these steps? > If a normal user cannot complete them, try as a superuser too. > Of course I am assuming the smack options are set to layer1. > > cd ./layer1 >> .wh..wh.aufs > ln .wh..wh.aufs .wh.0.txt >
Please find the details below # id uid=1001(test) gid=1001(test) groups=1001(test) # cat /proc/self/status | grep -i cap CapInh: 0000000000000000 CapPrm: 0000000000000000 CapEff: 0000000000000000 CapBnd: 0000003fffffffff # cat /proc/self/attr/current k1# # mkdir layer0 layer1 rootfs_mnt # echo 0 >layer0/0.txt # echo 1 >layer1/1.txt # # 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" # # cd layer1/ # >.wh..wh.aufs # ln .wh..wh.aufs .wh.0.txt # # chsmack .wh..wh.aufs .wh..wh.aufs access="k1" # chsmack .wh.0.txt .wh.0.txt access="k1" # chsmack rootfs_mnt/ rootfs_mnt/ access="k1" Now I mount the branches to rootfs_mnt in a root terminal as below mount -t aufs -o br=./layer1=rw:./layer0=ro -o udba=reval -o smackfsroot=k1 none ./rootfs_mnt As user test: ----------------- # for i in `find layer*`; do chsmack $i; done find: layer1/.wh..wh.plnk: Permission denied find: layer1/.wh..wh.orph: Permission denied layer0 access="k1" layer0/0.txt access="k1" layer1 access="k1" layer1/1.txt access="k1" layer1/.wh.0.txt access="k1" layer1/.wh..wh.aufs access="k1" layer1/.wh..wh.plnk access="_" layer1/.wh..wh.orph access="_" # # cd rootfs_mnt/ # # ls 1.txt # # rm 1.txt # > >> layer1/.wh..wh.aufs access="_" --------------> These meta data files >> are labelled "_" >> layer1/.wh..wh.plnk access="_" >> layer1/.wh..wh.orph access="_" > ::: >> Am I clear now? > > No. Sorry for not making it clear enough. > - Is the root cause of your problem that .wh..wh.aufs has access="_"? > - If so, why does it have access="_"? As the .wh..* files are created during mount they inherit the smack label of root. so they get access="_". > A simple creat(2) doesn't set the > attribute you want? > - If creat(2) is not good enough, then what is the correct way? Yes I can do a chown + chmod to .wh* files to make it accessible to user 'test'. Also I need to change their labels to "k1" because 1) User test has label "k1" 2) User test can't change the labels on its own as it lacks CAP_MAC_ADMIN 3) SMACK does not allow subjects (process with UID test) with label "k1" to do write operation on objects with label "_" > In order to give the light to these questions, I am asking the test of > creat(2) and link(2) manually. How can you get the result you want > manually? >From the root terminal I can change labels of all the .wh* files and can also change their ownership to normal user. This can be performed after the mount operation and it will allow me to get the desired result. Do you see any security risk in doing so? > > >> This option will chose the supplied smack label (k1) for the newly >> created aufs meta data files. >> In my case you can see the aufs meta data files (.wh..*.*) are labelled as >> "_". >> >> [This is happening because new objects get the label of subject. These >> files are created while mounting as a root user. The smack label for >> root user is "_". ] > > I am afraid such option violates the security policy of branch fs's or > smacks's. If it is acceptable, then why don't you set other label to > .wh..wh.aufs manually after mount(2)? Yes I am using this workaround now. Manually labeling the .wh* files > > Is this a natural-born-problem from a mixed use-case of smack and how > you mount aufs? Is their any way of differing the formation of .wh.* files till somebody really starts doing some file operations? In that way those files will always get the label of the guy who is doing the operation. The outline of our plan is given below |container0 | |containerrN | |Docker App0 | |Docker AppN | |Everything inside| - - |Everything inside| |labelled as k0 | |labelled as kN | |-----------------------| |----------------------| root user will label the layers and do aufs mount of the layers before starting the container. The processes running inside the container will also have a unique label such as k0,k1,... kN and they should be able to do any kind of operations in their respective aufs mounted directories. --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
