bug-coreutils
[Top][All Lists]
Advanced

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

Re: Problems with coreutils-6.12.70-4f470


From: Peter Fales
Subject: Re: Problems with coreutils-6.12.70-4f470
Date: Mon, 4 Aug 2008 09:22:47 -0500
User-agent: Mutt/1.4.2.3i

The problem occurs when you are not in /tmp, and do

        touch /tmp/foo
        mv -b /tmp/foo .

In qcopy_acl() (file copy-acl.c) around line 295, it reads  the ACL count
as 4, and then reads the ACLs with GETACL around line 320.  When it
turns around and sets these ACLs with SETACL around line 348, the call
to facl fails. 

Here are the values returned from the GETACL call:

(gdb) p entries[0]
$4 = {a_type = 1, a_id = 2008, a_perm = 6}
(gdb) p entries[1]
$5 = {a_type = 4, a_id = 2008, a_perm = 4}
(gdb) p entries[2]
$6 = {a_type = 16, a_id = -1, a_perm = 511}
(gdb) p entries[3]
$7 = {a_type = 32, a_id = -1, a_perm = 4}

I think the problem may be the a_id values of -1 which in turn are due
to the fact that /tmp has the "sticky" bit set.  There is nothing special
about foo itself:

$ ls -l /tmp/foo
-rw-r--r-- 1 expmake expmake 0 Aug  4 10:21 /tmp/foo

$ getfacl /tmp/foo

# file: /tmp/foo
# owner: expmake
# group: expmake
user::rw-
group::r--              #effective:r--
mask:rwx
other:r--

On Sat, Aug 02, 2008 at 09:19:10AM +0200, Jim Meyering wrote:
> Peter Fales <address@hidden> wrote:
> > I decided to have a look at the latest coreutils-6.12.70-4f470, and I'm
> > seeing a new problem on Solaris 8.  (Both sparc and x86)
> >
> > It seems that on Solaris, you can't simply copy the ACLs using GETACL/SETACL
> > if the source file is in /tmp.  This causes qcopy_acl() to fail with an
> > error, and can be demonstrated with the following program.  Copying the
> > ACLs from /foo works, but copying from /tmp/foo fails with EINVAL:
> 
> Thanks for investigating/reporting that.
> Unfortunately, copy-acl.c has several candidate acl/facl calls,
> and I don't have access to a Solaris 8 system on which to debug it.
> Do you know which one is affected in your case?
> There are already some attempts to handle EINVAL.
> 
> > ##################################################################
> > #include <sys/acl.h>
> > #include <sys/fcntl.h>
> >
> > main(int argc, char *argv[])
> > {
> > int count, fd, i, res;
> > aclent_t *entries;
> >
> >
> >     char *file[] = { "foo", "/tmp/foo" };
> >
> >     open("bar",O_WRONLY|O_CREAT,0644);
> >
> >     for ( i = 0 ; i < 2 ; i++ ) {
> >
> >             open(file[i],O_WRONLY|O_CREAT,0644);
> >
> >             count =  acl (file[i], GETACLCNT, 0, NULL);
> >
> >             entries = (aclent_t *) malloc (count * sizeof (aclent_t));
> >
> >             res = acl (file[i], GETACL, count, entries);
> >
> >             res = acl ("bar", SETACL, count, entries);
> >             if ( res < 0 ) {
> >                     perror(file[i]);
> >             }
> >     }
> > }
> > ##################################################################

-- 
Peter Fales
Alcatel-Lucent
Member of Technical Staff
2000 Lucent Lane
Room: 1C-436
Naperville, IL 60566-7033
Email: address@hidden
Phone: 630 979 8031




reply via email to

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