AUFS broken permissions? #20240
Comments
|
Ohhhh shut-up gordon, docker version is in there :) |
|
fwiw I couldn't reproduce(no boot2docker): https://gist.github.com/tonistiigi/d212392807dfd1e626ee |
|
I can also reproduce this (B2D 1.10, Ubuntu 15.10(kernel 4.2.0-27-generic)), and verified that
Dockerfile: FROM debian:jessie
RUN adduser --quiet testing
RUN mkdir -p /home/testing/d1/d2
RUN chmod 700 /home/testing/d1
RUN ls -lAR /home/testing
RUN chown -R testing:testing /home/testing/
RUN ls -lAR /home/testing
USER testing
RUN ls -lAR /home/testing |
|
This is really weird. I can make file accessible to the user by visiting them with root. |
thaJeztah
added
area/storage/aufs
kind/bug
|
I think I've seen a similar issue a while back (also same behavior, i.e., visiting as root magically made the permissions snap), searching if I can find it |
|
Think it was this one; #13823 (comment), which was related to incorrect umask being set, and resolved by #13941 |
|
I can confirm I've had the same issue that was presented here in my application. I'm using Ubuntu 14.04 with the v3.19 kernel update package installed (and AUFS, obviously). Like @thaJeztah and @tonistiigi pointed out, if you visit the directory as root, then the permissions start working. I haven't figured out a way to use that attribute to reliably work around the problem, though. I tried inserting commands in my Dockerfile to visit the directories as root, but the magic effect goes away when I create child containers from the resulting image. |
|
I can still reproduce the bug with Boot2Docker 1.10.2 + AUFS 20160223 (sfjro/aufs4-standalone@164e70a) |
|
Workaround: Run |
|
This is weird. My Linux host machine runs this: And the failing boot2docker was running this: That's why I decided to create a docker-machine with: Whose version is: ... And the bug still happens! |
|
I came across a different bug, but it's similar enough I might have chosen the same title. I have a docker image in which a non-root user cannot create any file in a specific directory to which that user supposedly has permission. Accessing the directory as root does not fix the problem, nor does changing the directory's attributes. However, renaming it (even as the non-root user) fixes it. Renaming it back to the original name also works. This is the only directory for which I've noticed the issue. I noticed this bug on a Google compute engine node to which I added docker (with AUFS): Docker info: Dockerfile: Output of docker build: Running it on my own workstation works as expected. My workstation is using the overlay driver. Docker info: |
|
Hi, I've been beaten by this bug few hours ago. I can confirm the behaviour : get broen permissions (?????) until you first "access" the resource as root. Env info : Cheers, |
|
Hi, I noticed and fixed this for myself last year but hadn't got around to reporting it.. :( It appears that the current implementation of aufs's dirperm1 doesn't use the correct permission overriding method when checking for whiteouts in dentry.c The below bash script can simulate the issue: #!/bin/bash
BASE=/root/aufsissue
BASE2=$BASE/aufs
#Create testuser
#adduser testissue
#Cleanup previous executions
umount $BASE2/mnt 2>/dev/null
rm -R $BASE2 2>/dev/null
#Setup a mount directory and two branches to be overlaid
mkdir $BASE2 $BASE2/branch1 $BASE2/branch2 $BASE2/mnt
#Mount branch1 on $BASE2/mnt
mount -t aufs -o dirperm1,dio,br:$BASE2/branch1=rw none $BASE2/mnt
#make two test directories on the lower branch
mkdir $BASE2/mnt/test1 $BASE2/mnt/test2
#Change permissions of two test directories
chmod -R 755 $BASE2/mnt/test1
chmod -R 700 $BASE2/mnt/test2
#Mount branch2 over branch1 in $BASE2/mnt
mount -t aufs -o remount,dirperm1,mod:$BASE2/branch1=ro+wh,prepend:$BASE2/branch2=rw none $BASE2/mnt
#Change ownership of two test directories
chown -R testissue:testissue $BASE2/mnt/test1
chown -R testissue:testissue $BASE2/mnt/test2
#Works correctly
echo
echo This works correctly
su testissue -c "touch $BASE2/mnt/test1/works"
#ls shows file was created
ls -lart $BASE2/branch2/test1
#Fails as unable to check for whiteouts with au_wh_test
#Even though the user "testissue" has ownership it cant read whiteouts
#from the lower branch with permission 700 because at the lower branch testissue isnt the owner.
#change dentry.c
#wh_found = au_wh_test(h_parent, wh_name, /*try_sio*/0);
#to
#wh_found = au_wh_test(h_parent, wh_name, /*try_sio*/ignore_perm);
echo
echo This fails
su testissue -c "touch $BASE2/mnt/test2/fails"
#ls shows no file was created
ls -lart $BASE2/branch2/test2I wrote the patch below for aufs and that fixed the issue for me - (it meant some kernel recompiling though): --- a/fs/aufs/dentry.c
+++ b/fs/aufs/dentry.c
@@ -57,7 +57,7 @@
br = au_sbr(dentry->d_sb, bindex);
wh_able = !!au_br_whable(br->br_perm);
if (wh_able)
- wh_found = au_wh_test(h_parent, wh_name, /*try_sio*/0);
+ wh_found = au_wh_test(h_parent, wh_name, ignore_perm);
h_dentry = ERR_PTR(wh_found);
if (!wh_found)
goto real_lookup;Regards Dave |
|
@TactfulElf That looks promising. Have you contributed the patch to the aufs project? That may be the best way of getting this fixed. |
|
@otherjason I've emailed aufs-users at lists.sourceforge.net hopefully someone will be able to review. |
|
Hi, I had an update from the aufs developer: Hello Dave, Thanx for the report and the patch. J. R. Okajima By the end of this month (today), aufs3.1[89] and aufs4.0 are not J. R. Okajima |
|
patch has been added to aufs >=4.(x>=1)-20160905 If you have an older aufs version <4.1 because of an older kernel I guess the only option is to apply the patch manually. sfjro/aufs4-standalone@625634d#diff-766898e31d29972e93ec410af8228d9a |
|
Is this issue closable? |
|
Looks like we should close this, yes, as it's not a bug in docker, and fixed upstream |
|
I was also affected by this bug in |
docker info
Dockerfile:
To reproduce, be sure to have a
contribfolder in the current directory, with at least one subfolder.Result:
docker build .The text was updated successfully, but these errors were encountered: