Re: `cp -p` incorrectly sets g+s bit when fs supports acl

[Jim Meyering]

Mike Frysinger wrote:
> On Saturday 23 February 2008 01:12:24 Mike Frysinger wrote:
>> On Saturday 23 February 2008, Paul Eggert wrote:
>> > Mike Frysinger <address@hidden> writes:
>> > > i'm using coreutils-6.10 with acl-2.2.47 on linux-2.6.24.  when using
>> > > ext2 with acl support enabled, `cp -p` on a directory who does not have
>> > > the g+s bit set but whose parent does have g+s set, the new destination
>> > > directory will have the g+s bit set.  if the filesystem is remounted
>> > > with acl support turned off, the g+s bit is (correctly) not set on the
>> > > new destination directory.
>> >
>> > Could you please strace the failing cp?  Thanks.
>>
>> here is the strace from a good and a bad run
>
> i just retested with latest software:
>  - coreutils-7.1
>  - acl-2.2.47
>  - linux-2.6.28

Thanks for the follow-up.

I agree that differences like this can be confusing,
and are best avoided, if at all possible.

FYI, this appears to be due to different policies:
Coreutils (copy.c) lets the mkdir syscall decide how
to handle set-GID bits.  Here's the relevant comment:

      if (new_dst || !S_ISDIR (dst_sb.st_mode))
        {
          /* POSIX says mkdir's behavior is implementation-defined when
             (src_mode & ~S_IRWXUGO) != 0.  However, common practice is
             to ask mkdir to copy all the CHMOD_MODE_BITS, letting mkdir
             decide what to do with S_ISUID | S_ISGID | S_ISVTX.  */
          if (mkdir (dst_name, dst_mode_bits & ~omitted_permissions) != 0)

so on Linux-based systems, people are used to seeing the set-?ID bits
inherited.  And that's the behavior you get without ACL support.
However, once you add ACLs/XATTRs to the mix, you are subject to their
policy, and when you say you want to copy all ACLs from one file to
another, you can't really expect the code to skip those special bits.

Eventually we might change GNU cp to manually preserve those
special bits, too, but first, we'll need to know how other
vendor cp programs work.  i.e., run the equivalent of your
reproducer from a year ago (start of this thread)

  http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/12795

on *BSD and Solaris-without-ACLs (if that's possible),
and report back how at least two of those other versions
of cp work.  If their cp -pr are unanimous in not propagating
the set-GID bit then I'll look into changing GNU cp.
Note that this will probably affect cross-partition mv, too,
since it uses the same code/options.