On Sat, Jan 7, 2017 at 7:51 PM, <sf...@users.sourceforge.net> wrote:
>
> Arun Chandran:
>> Are you going to fix this in your tree? Please feel free to ask my
>> help in testing it, I will happily do it.
>
> Thanx for testing.
> As you might know, aufs3.19 is not maintained now. So the tree won't be
> updated anymore. But similar issue will happen in aufs4.1 and later. I
> mean the supported branches. After a few more considerations and
> refining the patch, I MAY merge the patch into aufs4.1 and later. But
> aufs3.19 won't be updated.
>
>
> J. R. Okajima
Hi,
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/
As a normal user
# id
uid=1001(test) gid=1001(test) groups=1001(test)
# find layer*
layer0
layer0/etc
layer0/etc/0_3.txt
layer0/etc/0_2.txt
layer0/etc/0_1.txt
layer1
layer1/etc
layer1/etc/1_3.txt
layer1/etc/1_1.txt
layer1/etc/1_2.txt
layer2
layer2/.wh..wh.aufs
layer2/root
layer2/root/2_1.txt
layer2/root/2_3.txt
layer2/root/2_2.txt
layer2/.wh..wh.orph
find: layer2/.wh..wh.orph: Permission denied
#
# chsmack layer2/.wh..wh.orph
layer2/.wh..wh.orph access="_"
# chsmack layer2/.wh..wh.aufs
layer2/.wh..wh.aufs access="_"
#
# cd rootfs_mnt/etc/
#
# rm *
rm: can't remove '0_1.txt': Permission denied
rm: can't remove '0_2.txt': Permission denied
rm: can't remove '0_3.txt': Permission denied
rm: can't remove '1_1.txt': Permission denied
rm: can't remove '1_2.txt': Permission denied
rm: can't remove '1_3.txt': Permission denied
#
# cat /proc/self/attr/current
k1
#------------------> In another root terminal executed '# chsmack -a
k1 layer2/.wh..wh.aufs'
# rm *
---------------------> rm succeeded
Below are the audit messages from smack during the failure
###############
# dmesg -c
[ 857.268080] audit: type=1400 audit(1484226775.112:3): lsm=SMACK
fn=smack_inode_link action=denied subject="k1" object="_" requested=w
pid=180 comm="rm" name=".wh..wh.aufs" dev="hda1" ino=806
[ 857.304931] audit: type=1400 audit(1484226775.150:4): lsm=SMACK
fn=smack_inode_link action=denied subject="k1" object="_" requested=w
pid=180 comm="rm" name=".wh..wh.aufs" dev="hda1" ino=806
[ 857.318879] audit: type=1400 audit(1484226775.164:5): lsm=SMACK
fn=smack_inode_link action=denied subject="k1" object="_" requested=w
pid=180 comm="rm" name=".wh..wh.aufs" dev="hda1" ino=806
[ 857.327849] audit: type=1400 audit(1484226775.173:6): lsm=SMACK
fn=smack_inode_link action=denied subject="k1" object="_" requested=w
pid=180 comm="rm" name=".wh..wh.aufs" dev="hda1" ino=806
################
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 ?
--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
