ports/107229: gcp fails to set default ACL which causes OOo make failure
Jukka A. Ukkonen
jau at iki.fi
Wed Dec 27 08:20:13 UTC 2006
>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 at 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:
More information about the freebsd-ports-bugs
mailing list