bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Re-2: mv do not preserves default acls


From: Andreas Gruenbacher
Subject: Re: Re-2: mv do not preserves default acls
Date: Wed, 19 Oct 2005 22:03:30 +0200
User-agent: KMail/1.8

On Friday 07 October 2005 11:28, Jim Meyering wrote:
> address@hidden wrote:
> > ok I thing cp,mv etc. does support ACLs from stock. Well my disibution
> > (SUSE SLES9) preserves the ACLs (including default ACLs) when I perform
> > "cp" but it doesn`t work with "mv".
>
> That's odd.
> I was under the impression that SUSE's coreutils were patched
> to provide ACL support.  You should upgrade or report the problem to them.

That's true, SUSE's coreutils do include ACL support in all products since a 
long time.

Stefan in his original prosting reported that:
> I think there is a bug in the "mv" command. New files created by mv do not
> inherit their parent directory's default ACL entries (if any), but retain
> their original ACLs.  

This is by design: default ACLs define the permissions that get applied at 
file create time. A `cp' (without the -p option for preserving permissions) 
is handled like a file create. A `mv' logically is not a file create, and so 
the default ACL won't matter. That's the static POSIX ACL inheritance model 
as defined in the POSIX ACL drafts, and that's what all implementations I am 
aware of follow.

> > Where can I get the ACL-pachtes for the mv command?
>
> As far as I know, there are none for the latest test release.
> If you search for e.g., coreutils-5.3.0-10.src.rpm,
> you should find patches that will apply to the previous
> test release.

There are patches for coreutils-5.90 now -- I just updated the diffs. I'll 
happily send them if anyone is interested.

Jim, you wrote:
> We haven't integrated support for ACLs, yet.
> There are patches being used by several distributions.
> If there's interest, I'll begin distributing one of those
> patch sets -- and keeping it in sync -- so people don't have
> to struggle through merges all the time.

I would much more appreciate if you could finally integrate the patches, or if 
we could work out something that you consider mergeable by your standards. 
The patches haven't been merged for many years now, and I bet that on 90% of 
all systems that use coreutils they better had been merged upstream a long 
time ago.

Paul Eggert wrote:
> There is no standard for ACLs.  It is a real maintenance nightmare.
> 
> We'd like to support ACLs portably (I have drafted some code along
> those lines, but it's incomplete).  It's not as easy as it might
> appear.  (Check out the Samba code that deals with ACLs.  Yeouch!)
> 
> In the meantime, some vendors have patches that work with their
> particular platforms; that's an easier job.

There is a fair number of platforms that all support POSIX ACLs in one form or 
the other, including FreeBSD, Linux, Solaris, and many others. The platforms 
mostly differ in their acl library support.

It all depends on what you want to do: Samba tries to map the POSIX ACL model 
to the CIFS ACL model, which requires full access to all details of ACLs, so 
Samba implements an abstract intermediary Samba ACL model to abstract away 
details of the various POSIX ACL differences. Coreutils need to do only three 
things:

  - determine whether a file has any permissions set beyond bare POSIX,

  - copy an acl from one file to another (i.e., preserve permissions), and

  - set the acl of a file to the permissions represented by a set of file
    mode the permission bits.

That's what the patches floating around implement for a limited set of UNIX 
variants. IMHO that's a reasonable starting point, and support for more 
UNIXes can be added in a matter of hours. Coreutils include a number of 
optimizations that make no sense in the presence of ACLs, so maybe that's why 
there is so much resistance.

Thanks,
Andreas.

-- 
Andreas Gruenbacher <address@hidden>
SUSE Labs, SUSE LINUX PRODUCTS GMBH




reply via email to

[Prev in Thread] Current Thread [Next in Thread]