On Sat, Jan 14, 2017 at 11:20 AM, <sf...@users.sourceforge.net> wrote:
>
> Arun Chandran:
>> Now I moved my testing to 4.1.17(Used origin/aufs4.1.13+ from
>> aufs4-standalone + b.patch applied).
>>
>> As a root user mounted the layers:
>> # mount -t aufs -o
>> br=./layer2=rw:./layer1=ro:./layer0=ro:,noplink,smackfsdef=k1,smackfsroot=k1
>> -o udba=reval none ./rootfs_mnt/
> :::
>> Does that mean 'smackfsdef=k1' supplied while mouting don't have any
>> influence on the labels selected ("_") for
>> layer2/.wh..wh.aufs and layer2/.wh..wh.orph ?
>
> Hmm, it seems that I have to learn about smack. Honestly speaking I do
> know nothing about that.
> Anyway what is smackfsdef? It that a mount option for smackfs? If so, it
> has no effect. Or is it a generic mount option for any filesystem? If
> so, it should have an effect on aufs as well.
> What will happen if you specify smackfsdef for layer[012]?
>
>
> J. R. Okajima
Me too is not an expert on smack; just started using it now.
------------------
>From the doc:
------------------
Smack supports some mount options:
smackfsdef=label: specifies the label to give files that lack
the Smack label extended attribute.
smackfsroot=label: specifies the label to assign the root of the
file system if it lacks the Smack extended attribute.
smackfshat=label: specifies a label that must have read access to
all labels set on the filesystem. Not yet enforced.
smackfsfloor=label: specifies a label to which all labels set on the
filesystem must have read access. Not yet enforced.
--------------------------------------------------------------------------------------------
"k1" is the smack label given to all the branches and files in my setup
--------------------------------------------------------------------------------------------
# for i in `find layer*`; do chsmack $i; done
layer0 access="k1"
layer0/etc access="k1"
layer0/etc/0_3.txt access="k1"
layer0/etc/0_2.txt access="k1"
layer0/etc/0_1.txt access="k1"
layer1 access="k1"
layer1/etc access="k1"
layer1/etc/1_3.txt access="k1"
layer1/etc/1_1.txt access="k1"
layer1/etc/1_2.txt access="k1"
layer2 access="k1"
layer2/root access="k1"
layer2/root/2_1.txt access="k1"
layer2/root/2_3.txt access="k1"
layer2/root/2_2.txt access="k1"
I am running as a user "test" labeled as 'k1'
# id
uid=1001(test) gid=1001(test) groups=1001(test)
# cat /proc/self/attr/current
k1#
This means the subject (user test) has all the access (rwx) to objects
labelled as "k1"
-------------------------------------------------------------
Now from a root terminal I mount the branches
--------------------------------------------------------------
# mount -t aufs -o br=./layer2=rw:./layer1=ro:./layer0=ro -o
udba=reval -o noplink,smackfsdef=k1,smackfsroot=k1 none ./rootfs_mnt
#
# chsmack rootfs_mnt/
rootfs_mnt/ access="k1"
#
# id
uid=0(root) gid=0(root) groups=0(root),10(wheel)
#
# pwd
/home/test
----------------------------------------
After the mount the labels are
----------------------------------------
# for i in `find layer*`; do chsmack $i; done
find: layer2/.wh..wh.orph: Permission denied
layer0 access="k1"
layer0/etc access="k1"
layer0/etc/0_3.txt access="k1"
layer0/etc/0_2.txt access="k1"
layer0/etc/0_1.txt access="k1"
layer1 access="k1"
layer1/etc access="k1"
layer1/etc/1_3.txt access="k1"
layer1/etc/1_1.txt access="k1"
layer1/etc/1_2.txt access="k1"
layer2 access="k1"
layer2/.wh..wh.aufs access="_"
layer2/root access="k1"
layer2/root/2_1.txt access="k1"
layer2/root/2_3.txt access="k1"
layer2/root/2_2.txt access="k1"
layer2/.wh..wh.orph access="_"
#
The labels given to layer2/.wh..wh.orph and layer2/.wh..wh.orph is "_"
because it is formed by mount (running as root)
As the objects gets the label of the subject (root now) those files
got the labels "_". I thought they should be getting the labels from
"smackfsdef" and it seems I am wrong.
-----------------------------------------------------------------
User test unable to delete files from the mount dir
------------------------------------------------------------------
# cd rootfs_mnt/
#
# rm etc/*
rm: can't remove 'etc/0_1.txt': Permission denied
rm: can't remove 'etc/0_2.txt': Permission denied
rm: can't remove 'etc/0_3.txt': Permission denied
rm: can't remove 'etc/1_1.txt': Permission denied
rm: can't remove 'etc/1_2.txt': Permission denied
rm: can't remove 'etc/1_3.txt': Permission denied
#
#
# dmesg
[ 3429.784711] audit: type=1400 audit(1484377632.643:2): lsm=SMACK
fn=smack_inode_link action=denied subject="k1" object="_" requested=w
pid=409 comm="rm" name=".wh..wh.aufs" dev="hda1" ino=806
[ 3429.813012] audit: type=1400 audit(1484377632.671:3): lsm=SMACK
fn=smack_inode_link action=denied subject="k1" object="_" requested=w
pid=409 comm="rm" name=".wh..wh.aufs" dev="hda1" ino=806
[ 3429.817525] audit: type=1400 audit(1484377632.676:4): lsm=SMACK
fn=smack_inode_link action=denied subject="k1" object="_" requested=w
pid=409 comm="rm" name=".wh..wh.aufs" dev="hda1" ino=806
[ 3429.820807] audit: type=1400 audit(1484377632.678:5): lsm=SMACK
fn=smack_inode_link action=denied subject="k1" object="_" requested=w
pid=409 comm="rm" name=".wh..wh.aufs" dev="hda1" ino=806
[ 3429.830212] audit: type=1400 audit(1484377632.684:6): lsm=SMACK
fn=smack_inode_link action=denied subject="k1" object="_" requested=w
pid=409 comm="rm" name=".wh..wh.aufs" dev="hda1" ino=806
[ 3429.842098] audit: type=1400 audit(1484377632.700:7): lsm=SMACK
fn=smack_inode_link action=denied subject="k1" object="_" requested=w
pid=409 comm="rm" name=".wh..wh.aufs" dev="hda1" ino=806
As of now I can workaround this problem by manually labeling
".wh..wh.aufs" to "k1".
--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
