Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 27 Dec 2006 08:17:30 GMT
From:      "Jukka A. Ukkonen"<jau@iki.fi>
To:        freebsd-gnats-submit@FreeBSD.org
Subject:   ports/107229: gcp fails to set default ACL which causes OOo make failure
Message-ID:  <200612270817.kBR8HUo5062753@www.freebsd.org>
Resent-Message-ID: <200612270820.kBR8KDx4009570@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help

>Number:         107229
>Category:       ports
>Synopsis:       gcp fails to set default ACL which causes OOo make failure
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-ports-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Dec 27 08:20:12 GMT 2006
>Closed-Date:
>Last-Modified:
>Originator:     Jukka A. Ukkonen
>Release:        FreeBSD 6.2-PRERELEASE
>Organization:
private individual
>Environment:
FreeBSD mjolnir 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #1: Mon Dec 25 11:40:10 EET 2006     root@mjolnir:/usr/obj/usr/src/sys/Mjolnir  i386
>Description:
There is a problem in how gcp (GNU cp) interacts with the kernel to set
the default ACLs. Whether this is a problem in the kernel or a problem in
gcp or in both still remains unknown.

Because at the moment I have no way of knowing whether this is a problem in
gcp or in the kernel, I set the category of this PR to "ports". If it proves
to be a wrong guess, please, re-categorize this as "kern".


Anyhow the situation in which the symptoms were found goes as follows...


Building OpenOffice.org-2 fails on a system which uses ACLs as shown by
the mount options quoted below...

/dev/mirror/gm0f        /usr    ufs rw,multilabel,acls  2 2

The failure happens persistently when make reaches the following phase...

  adding: libssl3.so (deflated 55%)
  adding: libxpcom.so (deflated 65%)
  adding: libxpcom_compat.so (deflated 62%)
touch ./unxfbsdi.pro/misc/build/so_moz_runtime_files
You can delete ./unxfbsdi.pro/inc to force it copy all include files again.
/usr/local/bin/gcp -prL ./unxfbsdi.pro/misc/build/mozilla/dist/include/* ./unxfbsdi.pro/inc
/usr/local/bin/gcp: preserving permissions for `./unxfbsdi.pro/inc/addrbook': Invalid argument
/usr/local/bin/gcp: preserving permissions for `./unxfbsdi.pro/inc/appcomps': Invalid argument
/usr/local/bin/gcp: preserving permissions for `./unxfbsdi.pro/inc/appshell': Invalid argument
/usr/local/bin/gcp: preserving permissions for `./unxfbsdi.pro/inc/autoconfig': Invalid argument


To see further what is the trouble the obvious tools were ktrace + kdump.
The important news in the output was repeated for each of the gcp argument
files, but here is one sample...

        /* End of implementation class template. */
        #endif
        
        #define NS_GLOBALHISTORY_CONTRACTID \\
            "@mozilla.org/browser/global-history;1"
        
        #endif /* __gen_nsIGlobalHistory_h__ */
       "
 54815 gcp      RET   write 3143/0xc47
 54815 gcp      CALL  futimes(0x4,0xbfbfbef0)
 54815 gcp      RET   futimes 0
 54815 gcp      CALL  __acl_get_fd(0x3,0,0x8060200)
 54815 gcp      RET   __acl_get_fd 0
 54815 gcp      CALL  __acl_set_fd(0x4,0,0x8060200)
 54815 gcp      RET   __acl_set_fd 0
 54815 gcp      CALL  close(0x4)
 54815 gcp      RET   close 0
 54815 gcp      CALL  close(0x3)
 54815 gcp      RET   close 0
 54815 gcp      CALL  lstat(0x80590c0,0xbfbfc150)
 54815 gcp      NAMI  "./unxfbsdi.pro/inc/docshell"
 54815 gcp      RET   lstat 0
 54815 gcp      CALL  utimes(0x80590c0,0xbfbfc180)
 54815 gcp      NAMI  "./unxfbsdi.pro/inc/docshell"
 54815 gcp      RET   utimes 0
 54815 gcp      CALL  __acl_get_file(0xbfbfd18e,0,0x805f000)
 54815 gcp      NAMI  "./unxfbsdi.pro/misc/build/mozilla/dist/include/docshell"
 54815 gcp      RET   __acl_get_file 0
 54815 gcp      CALL  __acl_set_file(0x80590c0,0,0x805f000)
 54815 gcp      NAMI  "./unxfbsdi.pro/inc/docshell"
 54815 gcp      RET   __acl_set_file 0
 54815 gcp      CALL  __acl_get_file(0xbfbfd18e,0x1,0x805f000)
 54815 gcp      NAMI  "./unxfbsdi.pro/misc/build/mozilla/dist/include/docshell"
 54815 gcp      RET   __acl_get_file 0
 54815 gcp      CALL  __acl_set_file(0x80590c0,0x1,0x805f000)
 54815 gcp      NAMI  "./unxfbsdi.pro/inc/docshell"
 54815 gcp      RET   __acl_set_file -1 errno 22 Invalid argument
 54815 gcp      CALL  write(0x2,0xbfbfbb80,0x14)
 54815 gcp      GIO   fd 2 wrote 20 bytes
       "/usr/local/bin/gcp: "
 54815 gcp      RET   write 20/0x14
 54815 gcp      CALL  write(0x2,0xbfbfb770,0x38)
 54815 gcp      GIO   fd 2 wrote 56 bytes
       "preserving permissions for `./unxfbsdi.pro/inc/docshell'"
 54815 gcp      RET   write 56/0x38
 54815 gcp      CALL  write(0x2,0xbfbfb750,0x12)
 54815 gcp      GIO   fd 2 wrote 18 bytes
       ": Invalid argument"
 54815 gcp      RET   write 18/0x12


In that example calling acl_set_file() with the 2nd argument set to 0
(= ACL_TYPE_ACCESS) succeeds just fine, but calling it with the 2nd
argument set to 1 (= ACL_TYPE_DEFAULT) fails.
Apparently there is something odd about how gcp tries to set the default ACL
or in how the kernel interprets the default setting.

>How-To-Repeat:
One way to repeat the problem is described above in the full description of the
problem.
A simpler method might be simply creating a UFS2 file system with ACLs enabled
and then trying to manually copy a file or set of files using "gcp -prL".

>Fix:
No fix known yet.

>Release-Note:
>Audit-Trail:
>Unformatted:



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200612270817.kBR8HUo5062753>