Arun Chandran:
> "sudo mount .." gives correct labels. I can't use it because the
> containers don't get sudo inside ; container might be running with the
> lowest possible privileges.
Our discussion about the smack label is almost done. Thank you.
But I'd suggest you to consider other docker
On Mon, Jan 16, 2017 at 7:59 PM, wrote:
>
> Arun Chandran:
>> No with 'sudo mount ..' the .wh.* files are created with label of the
>> user test not with the label of root.
>> [This is because objects gets label of the process; label of user test
>> is "k1"; sudo is
Arun Chandran:
> No with 'sudo mount ..' the .wh.* files are created with label of the
> user test not with the label of root.
> [This is because objects gets label of the process; label of user test
> is "k1"; sudo is not changing label]
I see.
It may be a very basic building block of security
On Mon, Jan 16, 2017 at 6:39 PM, wrote:
>
> Arun Chandran:
>> No, It succeeded and created with label "k1", please see below
>
> Ok, then let's make sure again.
> - you wrote that the smack label for root user is "_".
Yes. That is correct.
# id
uid=0(root)
Arun Chandran:
> No, It succeeded and created with label "k1", please see below
Ok, then let's make sure again.
- you wrote that the smack label for root user is "_".
- "sudo mount -t aufs ..." created the file with access="_".
- "sudo touch ..." created with access="k1".
Why didn't "touch" and
On Mon, Jan 16, 2017 at 12:29 PM, wrote:
>
> Arun Chandran:
>> # id
>> uid=1001(test) gid=1001(test) groups=1001(test)
> :::
>> # cd layer1/
>> # >.wh..wh.aufs
>> # ln .wh..wh.aufs .wh.0.txt
>
> Ok, succeeded with a normal user.
> How about as a superuser?
>
Arun Chandran:
> # id
> uid=1001(test) gid=1001(test) groups=1001(test)
:::
> # cd layer1/
> # >.wh..wh.aufs
> # ln .wh..wh.aufs .wh.0.txt
Ok, succeeded with a normal user.
How about as a superuser?
cd layer1
sudo touch .wh..wh.aufs
ln .wh..wh.aufs .wh.0.txt
Is .wh..wh.aufs created
On Mon, Jan 16, 2017 at 1:19 AM, wrote:
>
> Arun Chandran:
>> -
>> Files in the layers before mounting
>> --
>> # for i in `find layer* `; do chsmack $i; done
>> layer0
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"
On Mon, Jan 16, 2017 at 12:08 AM, wrote:
>
> Arun Chandran:
>> 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
Arun Chandran:
> 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 "_"
Still I don't get the point.
Would you try these steps? I
On Sun, Jan 15, 2017 at 1:04 AM, Casey Schaufler 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
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
On Sat, Jan 14, 2017 at 11:20 AM, 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
>>
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/
On Sat, Jan 7, 2017 at 7:51 PM, 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
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
On Sat, Jan 7, 2017 at 6:51 PM, wrote:
> Arun Chandran:
>> Thank you for the quick reply.
>> I have tested the patch. 'ls' behavior is the same, it hangs. There
>> are no error messages coming now may be it is doing something inside
>> au_h_path_getattr() with
Arun Chandran:
> Thank you for the quick reply.
> I have tested the patch. 'ls' behavior is the same, it hangs. There
> are no error messages coming now may be it is doing something inside
> au_h_path_getattr() with holding the lock (When printed locked is -1).
Ah, it was necessary for
On Sat, Jan 7, 2017 at 2:15 AM, wrote:
> Hello Arun,
>
> Arun Chandran:
>> 4) Now if I cd to /mnt/mnt and do 'ls' it hangs and I get the below oops.
>>
>>
>> # dmesg
>> [ 148.855382] [ cut here ]
>> [ 148.855382] kernel BUG at
Hello Arun,
Arun Chandran:
> 4) Now if I cd to /mnt/mnt and do 'ls' it hangs and I get the below oops.
>
>
> # dmesg
> [ 148.855382] [ cut here ]
> [ 148.855382] kernel BUG at fs/aufs/sbinfo.c:336!
:::
That is interesting.
Smack enters aufs twice.
Generally a
Hi All,
I am using branch 'origin/aufs3.19' from
git://github.com/sfjro/aufs3-linux.git. and want to use smack with
aufs. So I enabled the option CONFIG_AUFS_XATTR and booted the kernel.
To test it I did
1) mount /dev/hdb1 to /mnt
# mount | grep hdb1
/dev/hdb1 on /mnt type ext4
22 matches
Mail list logo