GNU bug report logs - #8527
cp/mv in coreutils don't respect the default ACL of parent directories.

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 8527 in the body.
You can then email your comments to 8527 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: crocket <crockabiscuit <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: cp/mv in coreutils don't respect the default ACL of parent
	directories.
Date: Wed, 20 Apr 2011 23:24:14 +0900

I copied a file into a directory whose default ACL entries were d:u::rwx,
d:g::rwx, d:o::rx.
The original file's permission was 775.
The copied file's permission should have been 664 if default ACL was respected.
But the copied file's permission was 775, which is the same as the original
file.

The same happens with mv.

It seems like a bug.
I want every copied/moved file to respect default ACL by default.

Message #8 received at 8527 <at> debbugs.gnu.org (full text, mbox):

From: f0rhum <at> free.fr
To: 8527 <at> debbugs.gnu.org
Subject: Re: cp/mv in coreutils don't respect the default ACL of parent
Date: Fri, 3 Oct 2014 09:26:19 +0200 (CEST)

I can confirm. Tests show that the parent folder ACL "Default mask" is not inherited as the ACL "Access mask" of the file|dir created by cp|mv. 

Message #11 received at 8527 <at> debbugs.gnu.org (full text, mbox):

From: "Linda A. Walsh" <coreutils <at> tlinx.org>
To: f0rhum <at> free.fr
Cc: 8527 <at> debbugs.gnu.org
Subject: Re: bug#8527: cp/mv in coreutils don't respect the default ACL of
 parent
Date: Tue, 07 Oct 2014 03:08:54 -0700

f0rhum <at> free.fr wrote:
> I can confirm. Tests show that the parent folder ACL "Default mask" is not inherited as the ACL "Access mask" of the file|dir created by cp|mv. 
>

What file system and core utils are you using?

Are you using a file system that has alternate user-data forks
or extended attributes that have them included by default? 
Or are you using a file system where they were added on as a super-user 
control'd option?  Have you tried copying them as root?

The reason I ask, is that I just tried it and it appears to work:
1) First the dir:
>  cd /tmp
>  llg -d /tmp
drwxrwxrwt 25 root root 8192 Oct  7 02:21 /tmp/
>  lsacl /tmp
[u::rwx,g::rwx,o::rwx] /tmp               #default ACL from mode bits

2) Create file with 'touch'
>  touch x                                 # new file
Ishtar:/tmp> llg x
-rw-rw-r-- 1 law lawgroup 0 Oct  7 02:26 x
>  lsacl
[u::rw-,g::rw-,o::r--] x                  #default ACL
----
3) now I'll copy in a *directory* that has both types of ACL's on it, but
not specifying that any permissions be copied:

>  ll -d  /Media/Library/_artwork/test       #source
drwxrwsr-x+ 2 10 Oct  7 02:33 /Media/Library/_artwork/test/
Ishtar:/tmp> lsacl  /Media/Library/_artwork/test      
[u::rwx,u:Media:rwx,g::rwx,g:Media:rwx,m::rwx,o::r-x/u::rwx,u:Media:rwx,g::rwx,g:Media:rwx,m::rwx,o::r-x] 
/Media/Library/_artwork/test

(note, 2nd acl is default dir (lsacl uses "chacl -l")
Ishtar:/tmp> 'cp' -r /Media/Library/_artwork/test .  #recursive to tmp
Ishtar:/tmp> llg -d test
drwxrwxr-x 2 law lawgroup 6 Oct  7 02:34 test/
Ishtar:/tmp> lsacl test                              #no attr indicated
[u::rwx,g::rwx,o::r-x] test                          #default ACL shown
----
So far all seems fine.

4) Now lets copy the perms too:

Ishtar:/tmp> rd test
Ishtar:/tmp> 'cp' -a /Media/Library/_artwork/test .
Ishtar:/tmp> llg -d test
drwxrwsr-x+ 2 law Media 6 Oct  7 02:33 test/
Ishtar:/tmp> lsacl test                          #same ACL as source
[u::rwx,u:Media:rwx,g::rwx,g:Media:rwx,m::rwx,o::r-x/u::rwx,u:Media:rwx,g::rwx,g:Media:rwx,m::rwx,o::r-x] 
test

5) create file in that dir:

Ishtar:/tmp> cd test
Ishtar:/tmp/test> touch touched_file
Ishtar:/tmp/test> llg touched_file
-rw-rw-r--+ 1 law Media 0 Oct  7 02:42 touched_file
Ishtar:/tmp/test> lsacl touched_file
[u::rw-,u:Media:rwx,g::rwx,g:Media:rwx,m::rw-,o::r--] touched_file
---
File has expected inherited ACL.

6) Now ... lets use cp to copy a file w/o acls in:
(first create normal file under /tmp):

>  echo "perm test">/tmp/perm.txt
Ishtar:/tmp/test> llg /tmp/perm.txt
-rw-rw-r-- 1 law lawgroup 10 Oct  7 02:59 /tmp/perm.txt
Ishtar:/tmp/test> lsacl /tmp/perm.txt
[u::rw-,g::rw-,o::r--] /tmp/perm.txt
>  'cp' /tmp/perm.txt .
Ishtar:/tmp/test> llg perm.txt
-rw-rw-r--+ 1 law Media 10 Oct  7 03:01 perm.txt
Ishtar:/tmp/test> lsacl perm.txt
[u::rw-,u:Media:rwx,g::rwx,g:Media:rwx,m::rw-,o::r--] perm.txt

----
8) Looks the same to me...However, check this out:

Ishtar:/tmp/test> rm perm.txt
Ishtar:/tmp/test> cp /tmp/perm.txt . 
Ishtar:/tmp/test> llg /tmp/perm.txt
-rw-rw-r-- 1 law lawgroup 10 Oct  7 02:59 /tmp/perm.txt
Ishtar:/tmp/test> lsacl perm.txt

No acl this time, but same copy...or was it?

Note I was careful to use 'cp' most of the time when copying except
this last time, cuz:
>  alias cp
alias cp='cp --preserve=mode,timestamps'

my normal cp is an alias -- that says to preserve the mode. 
It wouldn't be able to do that if it allowed the default ACL
to be set on the file.

--------------
So, I don't know if this is related to your problem, but
cp appears to be working correctly here
filesystem = xfs (acls are always on as they came with the filesystem).
kernel=

Linux Ishtar 3.16.2-Isht-Van #1 SMP PREEMPT Tue Sep 9 18:26:43 PDT 2014 
x86_64 x86_64 x86_64 GNU/Linux


==================================

If this was any help -- great, if it was an annoyance,
just delete it and I can claim my dog ate my keyboard...
(funny things come out of dogs stomachs.... ;-))...

Message #14 received at 8527 <at> debbugs.gnu.org (full text, mbox):

From: f0rhum <at> free.fr
To: 8527 <at> debbugs.gnu.org
Subject: Re: cp/mv in coreutils don't respect the default ACL of parent
Date: Tue, 7 Oct 2014 22:05:10 +0200 (CEST)

Thank you Linda for extensive answer.
Just an additional info before I reply your questions: for my own tests I didn't use /tmp as target because the sticky bit could do something special (not sure). Instead I used /srv/test that I chown me:writers , set chmod -R u:rwX,g:srwX then setfacl --set as needed all this as root. The goal being having a group writers rwX, another group readers with rX on the tree and o:---, and ignore source perms if any.


> What file system and core utils are you using?

My target file system is ext4 (default mount options include acl and user_xattr , coreutils is 8.21 & kernel is 3.13.0-36-generic #63-Ubuntu SMP Wed Sep 3 21:30:07 UTC 2014 x86_64 GNU/Linux with embedded acl support out of the box).

> Are you using a file system that has alternate user-data forks
> or extended attributes that have them included by default?
> Or are you using a file system where they were added on as a super-user
> control'd option?  Have you tried copying them as root?

I know this:
from local, umask=0002
from ssh,   umask=0022
no cp aliases, I just need/use the default, i.e. do-not-preserve-perms
All my tests below are run locally. So I wrote a script that echoes each line:
sudo ~/acl.sh
0 mkdir -pv /srv/test
0 setfacl -bk /srv/test
0 rm -rf /srv/test/*
ownership of /srv/test was kept as me:writers
0 chown -Rv me:writers /srv/test
mode of /srv/test/ was changed from 2770 (rwxrws---) to 0000 (---------)
0 (removed all bits)
mode of /srv/test/ was changed from 0000 (---------) to 2770 (rwxrws---)
0 chmod -Rv u+rwX,g+srwX /srv/test
0 setfacl -R --set d:u::rwx,d:g::rwx,d:g:writers:rwx,d:u:reader:rx,d:g:reader:rx,d:o::---,d:m::rwx /srv/test
getfacl: remove first "/" out of absolute path names
# file: srv/test
USER   me               rwx  rwx
user   reader                r-x
GROUP  writers          rwx  rwx
group  reader                r-x
group  writers               rwx
mask                         rwx
other                   ---  ---

0 setfacl -R --set u::rwX,g::rwX,u:reader:rX,g:writers:rwX,g:reader:rx,o::---,m::rwX /srv/test
getfacl: remove first "/" out of absolute path names
# file: srv/test
USER   me               rwx  rwx
user   reader           r-x  r-x
GROUP  writers          rwx  rwx
group  reader           r-x  r-x
group  writers          rwx  rwx
mask                    rwx  rwx
other                   ---  ---

****So at the moment this last command shows all is alright****
****                   Now, let's copy                     ****
me <at> pc:/srv$ cp -r /media/me/USPEED/200402/ /srv/test
me <at> pc:/srv$ getfacl -t /srv/test/200402/
getfacl: remove first "/" out of absolute path names
# file: srv/test/200402/
USER   me               rwx  rwx
user   reader           R-X  r-x
GROUP  writers          RWX  rwx
group  reader           R-X  r-x
group  writers          RWX  rwx
mask                    ---  rwx
other                   ---  ---

***problems begin: defaults ACL are kept OK (right perm column, ***
***but Access ACL are lost (capitalized in left column by -t are the denied perms because mask is lost, do not confuse with cap X in chmod)***
***only file owner can traverse, nobody else can)***

me <at> pc:/srv$ getfacl -t /srv/test/200402/P2220368.JPG 
getfacl: remove first "/" out of absolute path names
# file: srv/test/200402/P2220368.JPG
USER   me               rw-     
user   reader           r-X     
GROUP  writers          rWX     
group  reader           r-X     
group  writers          rWX     
mask                    r--     
other                   ---
*** Here one see writers lost the write perm, and reader could read if only he could traverse above***

Do the same by creation:
me <at> pc:/srv$ mkdir test/handdir
me <at> pc:/srv$ touch test/handdir/file
me <at> pc:/srv$ getfacl -Rt test/handdir/
# file: test/handdir/
USER   me               rwx  rwx
user   reader           r-x  r-x
GROUP  writers          rwx  rwx
group  reader           r-x  r-x
group  writers          rwx  rwx
mask                    rwx  rwx
other                   ---  ---

# file: test/handdir//file
USER   me               rw-     
user   reader           r-X     
GROUP  writers          rwX     
group  reader           r-X     
group  writers          rwX     
mask                    rw-     
other                   ---
***all is OK this way***








> The reason I ask, is that I just tried it and it appears to work:
> 1) First the dir:
> >  cd /tmp
> >  llg -d /tmp
> drwxrwxrwt 25 root root 8192 Oct  7 02:21 /tmp/
> >  lsacl /tmp
> [u::rwx,g::rwx,o::rwx] /tmp               #default ACL from mode bits
> 
> 2) Create file with 'touch'
> >  touch x                                 # new file
> Ishtar:/tmp> llg x
> -rw-rw-r-- 1 law lawgroup 0 Oct  7 02:26 x
> >  lsacl
> [u::rw-,g::rw-,o::r--] x                  #default ACL
> ----
> 3) now I'll copy in a *directory* that has both types of ACL's on it, but
> not specifying that any permissions be copied:
> 
> >  ll -d  /Media/Library/_artwork/test       #source
> drwxrwsr-x+ 2 10 Oct  7 02:33 /Media/Library/_artwork/test/
> Ishtar:/tmp> lsacl  /Media/Library/_artwork/test      
> [u::rwx,u:Media:rwx,g::rwx,g:Media:rwx,m::rwx,
> o::r-x/u::rwx,u:Media:rwx,
> g::rwx, g:Media:rwx,m::rwx,o::r-x]
> /Media/Library/_artwork/test

> (note, 2nd acl is default dir (lsacl uses "chacl -l")
> Ishtar:/tmp> 'cp' -r /Media/Library/_artwork/test .  #recursive to tmp
> Ishtar:/tmp> llg -d test
> drwxrwxr-x 2 law lawgroup 6 Oct  7 02:34 test/
> Ishtar:/tmp> lsacl test                              #no attr indicated
> [u::rwx,g::rwx,o::r-x] test                          #default ACL shown
> ----
> So far all seems fine.
> 
> 4) Now lets copy the perms too:

> Ishtar:/tmp> rd test
> Ishtar:/tmp> 'cp' -a /Media/Library/_artwork/test .
> Ishtar:/tmp> llg -d test
> drwxrwsr-x+ 2 law Media 6 Oct  7 02:33 test/
> Ishtar:/tmp> lsacl test                          #same ACL as source
> [u::rwx,u:Media:rwx,g::rwx,g:Media:rwx,
> m::rwx,o::r-x/u::rwx,u:Media:rwx,g::rwx,
> g:Media:rwx,m::rwx,o::r-x]
> test

> 5) create file in that dir:

> Ishtar:/tmp> cd test
> Ishtar:/tmp/test> touch touched_file
> Ishtar:/tmp/test> llg touched_file
> -rw-rw-r--+ 1 law Media 0 Oct  7 02:42 touched_file
> Ishtar:/tmp/test> lsacl touched_file
> [u::rw-,u:Media:rwx,g::rwx,g:Media:rwx,m::rw-,o::r--] touched_file
> ---
> File has expected inherited ACL.

> 6) Now ... lets use cp to copy a file w/o acls in:
> (first create normal file under /tmp):
> 
> >  echo "perm test">/tmp/perm.txt
> Ishtar:/tmp/test> llg /tmp/perm.txt
> -rw-rw-r-- 1 law lawgroup 10 Oct  7 02:59 /tmp/perm.txt
> Ishtar:/tmp/test> lsacl /tmp/perm.txt
> [u::rw-,g::rw-,o::r--] /tmp/perm.txt
> >  'cp' /tmp/perm.txt .
> Ishtar:/tmp/test> llg perm.txt
> -rw-rw-r--+ 1 law Media 10 Oct  7 03:01 perm.txt
> Ishtar:/tmp/test> lsacl perm.txt
> [u::rw-,u:Media:rwx,g::rwx,g:Media:rwx,m::rw-,o::r--] perm.txt
> 
> ----
> 8) Looks the same to me...However, check this out:
> 
> Ishtar:/tmp/test> rm perm.txt
> Ishtar:/tmp/test> cp /tmp/perm.txt .
> Ishtar:/tmp/test> llg /tmp/perm.txt
> -rw-rw-r-- 1 law lawgroup 10 Oct  7 02:59 /tmp/perm.txt
> Ishtar:/tmp/test> lsacl perm.txt
> 
> No acl this time, but same copy...or was it?
> 
> Note I was careful to use 'cp' most of the time when copying except
> this last time, cuz:
>  alias cp
> alias cp='cp --preserve=mode,timestamps'
> 
> my normal cp is an alias -- that says to preserve the mode.
> It wouldn't be able to do that if it allowed the default ACL
> to be set on the file.

> --------------
> So, I don't know if this is related to your problem, but
> cp appears to be working correctly here
> filesystem = xfs (acls are always on as they came with the filesystem).
> kernel=
> 
> Linux Ishtar 3.16.2-Isht-Van #1 SMP PREEMPT Tue Sep 9 18:26:43 PDT 2014
> x86_64 x86_64 x86_64 GNU/Linux

Message #17 received at 8527 <at> debbugs.gnu.org (full text, mbox):

From: Linda Walsh <coreutils <at> tlinx.org>
To: bug-coreutils <at> gnu.org
Cc: 8527 <at> debbugs.gnu.org
Subject: Re: bug#8527: cp/mv in coreutils don't respect the default ACL of
 parent
Date: Tue, 07 Oct 2014 18:06:45 -0700

Sorry, I didn't forward this to the right list...

The user data / extended attribute forks are where linux store the 
ACL's.  ext4 should
be configurable to do what you want to do, but I haven't personally used 
it -- but
I understand it has similar functionality as xfs.  The process umask is 
a masking
off of privs/permissions one sets on a normal file (ACL's aside).  It 
affects the
permission bits on the file   So if your umask was 077, then you open a 
file for
rwx rwx rwx, it would mask off group and other allowing the permissions 
to be
700 or rwx, --- ---.  (I might have the order backwards, but it's the 
standard
order you see in ls with numeric permissions)...Your umask will affect 
your file
mode creation, but it depends on what flags you use when you use 'cp' -- 
which is one
of the main points of my "detail"... after everything was shown to be 
working correctly
in my case, a setting I have in an "alias" to my "cp" would have 
over-ridden any
other settings and made it look like 'cp' ignored directory ACL or 
(sounds like you might
be talking group-owner ship -- of a dir -- or are you talking both).

Really, I'm not a member of the core utils devel group, so I really 
prefer you send your
answers and questions there, as they'll catch alot more things than I 
would -- I was
just showing an example of how your setting can override everything you 
think you are
setting -- so you'll need to provide more detail about what your umask 
is, (type umask at
prompt to see), and whether or not you have any aliases or ENV vars in 
effect that could
alter things.  If you can give an exact formula along the lines of what 
I did to
demonstrate your problem, that will help the developers the most.  The 
detail I gave
was only to show how things you don't think of may be affecting you and 
to be sure to check for them.  I'm cc'ing the list on my reply, but 
leaving your email off of it, so if you want to ask them if they need 
more information that's fine... otherwise, write down the exact
commands you typed and your environment, to repeat it.. (umask included).

If you want to use my lsacl script.. it's a trivial build on top of the 
chacl
program.  But please post to the list so everyone can be on the same 
page....
----lsacl script ----
more lsacl
#!/bin/bash
acllen=0
for fn in "$@"; do
 out="$(chacl -l "$fn")"
 qfn=$(printf "%q " "$fn")
 perm="${out#$qfn}"
 thislen=${#perm}
 if ((thislen>acllen)); then acllen=$thislen; fi
 printf "%-${acllen}s %s\n" "$perm" "$fn"
done
=====================================
Very trivial... but allowed  me to look at multiple files at a time...


IF you can give a recipe or script that duplicates the problem you saw, 
that would
be the best way to move this bug along (toward cockpit error or new 
special case found!).
Best of luck either way!

Message #23 received at 8527 <at> debbugs.gnu.org (full text, mbox):

From: f0rhum <at> free.fr
To: 8527 <at> debbugs.gnu.org
Subject: Re: cp/mv in coreutils don't respect the default ACL of parent
Date: Wed, 8 Oct 2014 11:57:08 +0200 (CEST)

And creations in the copied dir are OK:
Here the ~faulty~ acl for memory:
# file: srv/test/200402/
USER   me               rwx  rwx
user   reader           R-X  r-x
GROUP  writers          RWX  rwx
group  reader           R-X  r-x
group  writers          RWX  rwx
mask                    ---  rwx
other                   ---  ---

Then creations
me <at> pc:/srv$ mkdir test/200402/dir
me <at> pc:/srv$ touch test/200402/dir/file
   
me <at> pc:/srv$ getfacl -Rt test/200402/dir
# file: test/200402/dir
USER   me               rwx  rwx
user   reader           r-x  r-x
GROUP  writers          rwx  rwx
group  reader           r-x  r-x
group  writers          rwx  rwx
mask                    rwx  rwx
other                   ---  ---

# file: test/200402/dir/file
USER   me               rw-     
user   reader           r-X     
GROUP  writers          rwX     
group  reader           r-X     
group  writers          rwX     
mask                    rw-     
other                   ---

Are OK regard to the parent's correct "Default mask", but only me as the USER can do this because other writers lost rwx on parent copy (200402 dir)

Message #26 received at 8527 <at> debbugs.gnu.org (full text, mbox):

From: Dolf Andringa <dolfandringa <at> gmail.com>
To: 8527 <at> debbugs.gnu.org
Subject: Any updates on this?
Date: Sat, 11 Apr 2015 10:59:27 +0000

[Message part 1 (text/plain, inline)]

Hey All,

Many people on the internet seem to have stumbled across this bug, so much
so that the ubuntu docs on
https://help.ubuntu.com/community/FilePermissionsACLs even report that
ACL's are rendered ineffective due to this bug in coreutils (cp/mv). I have
run across this bug as well, which is very annoying in a shared environment
with multiple users in different groups using the same resources. Is there
any chance this bug will ever be fixed or is maintenance on ACL's or
coreutils not happening?
Regards,

Dolf.

[Message part 2 (text/html, inline)]

Message #29 received at 8527 <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Dolf Andringa <dolfandringa <at> gmail.com>, 8527 <at> debbugs.gnu.org
Subject: Re: bug#8527: Any updates on this?
Date: Sun, 12 Apr 2015 11:47:23 +0200

unarchive 18748
forcemerge 18748 8527
stop

On 04/11/2015 12:59 PM, Dolf Andringa wrote:
> Hey All,
> 
> Many people on the internet seem to have stumbled across this bug, so much so that the ubuntu docs on
> https://help.ubuntu.com/community/FilePermissionsACLs even report that ACL's are rendered ineffective due to this bug in
> coreutils (cp/mv). I have run across this bug as well, which is very annoying in a shared environment with multiple
> users in different groups using the same resources. Is there any chance this bug will ever be fixed or is maintenance on
> ACL's or coreutils not happening?
> Regards,
> 
> Dolf.

This has been discussed in several other threads; please see my
last post on this here:
  http://bugs.gnu.org/18748#29

Have a nice day,
Berny

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.