Bug 107229 - sysutils/coreutils: gcp fails to set default ACL which causes OOo make failure
Summary: sysutils/coreutils: gcp fails to set default ACL which causes OOo make failure
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-openoffice (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-12-27 08:20 UTC by jau
Modified: 2009-12-19 16:37 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jau 2006-12-27 08:20:12 UTC
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.

Fix: 

No fix known yet.
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".
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2007-01-12 14:11:22 UTC
State Changed
From-To: open->feedback

To which port does this PR apply? 


Comment 2 Mark Linimon freebsd_committer freebsd_triage 2007-01-12 14:11:22 UTC
Responsible Changed
From-To: freebsd-ports-bugs->linimon
Comment 3 Mark Linimon freebsd_committer freebsd_triage 2007-01-12 23:18:49 UTC
State Changed
From-To: feedback->open

Feedback received. 


Comment 4 Mark Linimon freebsd_committer freebsd_triage 2007-01-12 23:18:49 UTC
Responsible Changed
From-To: linimon->freebsd-ports-bugs
Comment 5 jharris 2007-01-16 00:16:14 UTC
>ports/107229: sysutils/coreutils: gcp fails to set default ACL which causes
>OOo make failure

Try the coreutils upgrade in PR ports/107954 first.  If that doesn't
help, try debugging the problem with getfacl(1) and setfacl(1).
After that, try asking on the coreutils mailing list(s).
Comment 6 Mathias Picker 2007-03-11 11:13:47 UTC
This problem still exists. The update to coreutils 6.7 does nothing to
solve it. Now asking the coreutils mailing list.
Comment 7 jau 2007-03-11 11:50:21 UTC
Quoting Mathias Picker:
> 
> This problem still exists. The update to coreutils 6.7 does nothing to
> solve it. Now asking the coreutils mailing list.

	Apparently the problem is that gcp tries to set the default
	ACL also on non-directory files.
	The current FreeBSD manual pages explain that default ACLs
	are only allowed for directories. And since default a ACL is
	something a new file or directory created under an existing
	directory should inherit by default as their initial ACLs,
	this makes perfect sense.

	The correct behaviour for gcp would be to either
	- not even try to set the default ACL for anything else but
	directories or
	- ignore the error returned unless the target is a directory.

	Apparently some other environments allow setting default ACLs
	for non-directory files and quietly ignore the issue, though,
	setting the default value makes no sense, because other files
	can inherit their initial ACLs only from the defaults set to
	their parent directories.


	Cheers,
		// jau
.---  ..-  -.-  -.-  .-    .-  .-.-.-    ..-  -.-  -.-  ---  -.  .  -.
  /    Jukka A. Ukkonen,                             Oxit Ltd, Finland
 /__   M.Sc. (sw-eng & cs)                    (Phone) +358-500-606-671
   /   Internet: Jukka.Ukkonen(a)Oxit.Fi        (Home) +358-9-6215-280
  /    Internet: jau(a)iki.fi
 v
        .---  .-  ..-  ...-.-  ..  -.-  ..  .-.-.-  ..-.  ..
+ + + + My opinions are mine and mine alone, not my employers. + + + +
Comment 8 HASHI Hiroaki 2007-03-23 09:42:02 UTC
This problem is caused by the following conditions.

   - preserve permissions. (-p)
   - copy a directory. (-r)
   - source directory have no default acl.

at copy_acl in lib/acl.c
    acl_get_file return a zero count acl if a source directory have no
    default acl.(acl->ats_acl.acl_cnt == 0)

    acl_set_file return with error EINVAL, if acl is zero count.

In this case, /bin/cp is not copy default acl.

at preserve_dir_acls in src/bin/cp/util.c
        if (aclp->acl_cnt != 0 && aclsetf(dest_dir,
            ACL_TYPE_DEFAULT, acl) < 0) {

fix patch following

--- lib/acl.c~	Tue Sep 26 00:52:29 2006
+++ lib/acl.c	Fri Mar 23 16:34:24 2007
@@ -280,7 +280,7 @@
 	  return -1;
 	}
 
-      if (acl_set_file (dst_name, ACL_TYPE_DEFAULT, acl))
+      if (acl->ats_acl.acl_cnt > 0 && acl_set_file (dst_name, ACL_TYPE_DEFAULT, acl))
 	{
 	  error (0, errno, _("preserving permissions for %s"),
 		 quote (dst_name));
Comment 9 Li-Wen Hsu freebsd_committer 2007-04-23 03:19:23 UTC
Responsible Changed
From-To: freebsd-ports-bugs->lwhsu

Since I took 111489, I'll take this.
Comment 10 Li-Wen Hsu freebsd_committer 2007-04-23 03:28:03 UTC
Hello,

Please take a look at ports/111489:
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/111489

Does upgrading to version 6.9 solve this issue?
If so, I will close this PR, and commit ports/111489.

Thanks in advanced.

-- 
Best Regards,
Li-Wen Hsu
Comment 11 Li-Wen Hsu freebsd_committer 2007-04-23 03:59:16 UTC
State Changed
From-To: open->feedback

Waiting for feedback.
Comment 12 Li-Wen Hsu freebsd_committer 2007-06-05 10:52:58 UTC
State Changed
From-To: feedback->closed

ports/111489 has been committed, and it's feeedback timeout on this PR. 
Please tell me if the problem still occurs, I'll reopen this PR.
Comment 13 hashiz 2007-06-11 10:38:22 UTC
Hello.

This problem still exist.

I upgrade sysutils/coreutils 6.7 to 6.9, and building
editors/openoffice-2 2.2.0_1.

It was stopped with following errors.

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/zlib': Invalid argument
dmake:  Error code 3, while making
'./unxfbsdi.pro/misc/build/so_moz_include_files'
'---* tg_merge.mk *---'

ERROR: Error 65280 occurred while making /usr/ports/editors/openoffice.org-2/work/OOF680_m14/moz
dmake:  Error code 1, while making 'build_instsetoo_native'
'---*  *---'
*** Error code 255

Stop in /usr/ports/editors/openoffice.org-2.
Comment 14 Li-Wen Hsu freebsd_committer 2007-06-11 12:04:19 UTC
State Changed
From-To: closed->open

The problem still occurs.
Comment 15 Denis Eremenko <moonshade@pnhz.kz> 2007-07-18 05:09:17 UTC
hasi@cskk-sv.co.jp is right.
copy_acl() from coreutils assumes acl_set_file() is linux one, which has
an extension over posix1e to accept zero sized default ACL.

FreeBSD's acl_set_file() doesn't do that (see base cp code).

--- lib/acl.c.orig	Mon Jul 16 11:03:58 2007
+++ lib/acl.c	Mon Jul 16 11:32:49 2007
@@ -129,7 +129,14 @@
 	  return -1;
 	}
 
-      if (acl_set_file (dst_name, ACL_TYPE_DEFAULT, acl))
+      /* From Linux acl_set_file(3) manpage:
+	    " The behavior of acl_set_file() when the acl parameter refers
+	    to an empty ACL and the type parameter is ACL_TYPE_DEFAULT
+	    is an extension in the Linux implementation, in order that
+	    all values returned by acl_get_file() can be passed to
+	    acl_set_file(). "
+      /* Zero size ACL should be checked, like
in /usr/src/bin/cp/utils.c:396 */
+      if (acl->ats_acl.acl_cnt != 0 && acl_set_file (dst_name,
ACL_TYPE_DEFAULT, acl))
 	{
 	  error (0, errno, _("preserving permissions for %s"),
 		 quote (dst_name));
Comment 16 Li-Wen Hsu freebsd_committer 2007-07-23 12:32:01 UTC
State Changed
From-To: open->feedback

Ask for maintainer approval.
Comment 17 Denis Eremenko <moonshade@pnhz.kz> 2007-08-16 11:45:54 UTC
People in freebsd-openoffice@freebsd.org keep asking... Is maintainer
alive?
Comment 18 Li-Wen Hsu freebsd_committer 2007-10-03 09:59:58 UTC
Responsible Changed
From-To: lwhsu->openoffice

Maintainer seems gone, and I think it's best to let openoffice people to 
decide whether committing this patch or not.
Comment 19 yuri 2008-01-27 01:27:35 UTC
OpenOffice still fails to compile.
Is anyone looking into this?

Who is the contact in OO team who can apply this patch?

Yuri
Comment 20 Martin Wilke freebsd_committer 2009-05-31 00:01:36 UTC
State Changed
From-To: feedback->open

.
Comment 21 Martin Wilke freebsd_committer 2009-05-31 00:01:46 UTC
State Changed
From-To: open->feedback

Could you please test if this issue still exists with an fresh ports 
tree? Thanks for your report.
Comment 22 Pav Lucistnik freebsd_committer 2009-12-19 16:28:52 UTC
State Changed
From-To: feedback->closed

I think this is fixed in coreutils-7.5 (current version of coreutils port)