Bug 1257153
Summary: | coreutils fails to rebuild as nonroot | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Karel Volný <kvolny> |
Component: | coreutils | Assignee: | Ondrej Vasik <ovasik> |
Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | qe-baseos-daemons |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 7.2 | CC: | kdudka, kvolny, pbrady |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2015-09-02 12:51:29 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Karel Volný
2015-08-26 11:33:47 UTC
rpmbuild depends on the operating system where you run the build - use mock and rhel 7 mock config if you want to avoid it. I expect underlying operating system is causing the test to fail. Can you please provide more information about your system where you run the rpmbuild? (For some reasons on your machine parent dirs are created with 755 mode instead of 700, although umask is set to 077. Strange, looks like not correctly working umask on your system.) (In reply to Ondrej Vasik from comment #2) > Can you please provide more information about your system where you run the rpmbuild? the log is from RHEL 7 Server stablesystem, but I've seen failures on other machines too - please see the TPS results in ET for a list of machines As you can see in http://download.devel.redhat.com/brewroot/work/tasks/6234/9766234/build.log scratch build passes and both tests as well in brew build root ( http://download.devel.redhat.com/brewroot/work/tasks/6234/9766234/root.log for the list of packages used in the build root - you can compare what differs ). I suspect some strange settings in beaker environment, however I don't plan to further investigate this issue in near future. Another cause could be default ACLs: $ mkdir /tmp/dir $ setfacl -dm group::rx /tmp/dir $ setfacl -dm other::rx /tmp/dir $ umask 077 $ mkdir /tmp/dir/new $ ls -dl /tmp/dir/new drwxr-xr-x+ 2 kdudka kdudka 4096 Aug 31 10:44 /tmp/dir/new Could you please re-check this on a file system mounted with the 'noacl' option? (In reply to Kamil Dudka from comment #7) > Could you please re-check this on a file system mounted with the 'noacl' > option? this doesn't seem to be the problem the build has just passed on another testing machine, and it has ACLs enabled /dev/mapper/... on / type xfs (rw,relatime,seclabel,attr2,inode64,noquota) /dev/mapper/... on /home type xfs (rw,relatime,seclabel,attr2,inode64,noquota) while the machine where the tests fail has the same options /dev/mapper/... on / type xfs (rw,relatime,seclabel,attr2,inode64,noquota) and they both have empty defaults like: $ getfacl -d / getfacl: Removing leading '/' from absolute path names # file: . # owner: root # group: root $ getfacl -d /home getfacl: Removing leading '/' from absolute path names # file: home # owner: root # group: root (or am I missing something, is there anything else to compare about ACLs?) How exactly do you run the tests? Is there any RHTS test we can try ourselves? I could not find any coreutils test invoking 'rpmbuild --rebuild'. it is just manual rebuild - the rebuild test is part of TPS, but due to historical reasons it runs as root which fails too, so I've just retried that manually on the stablesystems that picked the TPS jobs ping me on irc for details about accessing the systems, if needed Thank you for granting me the access, Karel. I have confirmed this is really an issue with default ACLs: $ getfacl /home/test getfacl: Removing leading '/' from absolute path names # file: home/test # owner: test # group: test user::rwx group::--- other::--- default:user::rwx default:group::--- default:other::--- After clearing the default ACLs on ~/rpmbuild, coreutils builds as expected: $ setfacl -k -R ~/rpmbuild (In reply to Kamil Dudka from comment #12) > Thank you for granting me the access, Karel. you're welcome and I thank you for taking a look because this isn't exactly my cup of tea and it would take me a long time to get into it (if I had the time ...) > I have confirmed this is > really an issue with default ACLs: > > $ getfacl /home/test > getfacl: Removing leading '/' from absolute path names > # file: home/test > # owner: test > # group: test > user::rwx > group::--- > other::--- > default:user::rwx > default:group::--- > default:other::--- now that's interesting where does it come from - as you can see in comment #8 there was no default and now, on the same machine, I see # getfacl -d /home/ getfacl: Removing leading '/' from absolute path names # file: home/ # owner: root # group: root user::rwx group::r-x other::r-x ... it didn't come to my mind to test $HOME and not just /home before, though > After clearing the default ACLs on ~/rpmbuild, coreutils builds as expected: > > $ setfacl -k -R ~/rpmbuild yep, I can confirm do you think you would be able to find out where the bad ACLs come from? - I doubt that someone sets that manually just to cause coreutils to fail tests, it must come from some system misconfiguration or new package misbehaviour, I smell some regression here ... Anyway, not a bug in coreutils package itself - keeping opened only until clarified. In any case, potential misconfiguration or regression will likely be reported in separate bugzilla. (In reply to Karel Volný from comment #14) > do you think you would be able to find out where the bad ACLs come from? Not really. Assuming the default ACLs are not set on a fresh el7 installation, you need to check your scripts to see at which point they appear. I am pretty sure it is not coreutils what introduces them. (In reply to Kamil Dudka from comment #16) > Not really. Assuming the default ACLs are not set on a fresh el7 > installation, you need to check your scripts to see at which point they > appear. it surely doesn't come from "my" or "our" scripts; the other machine mentioned in #c8 has been installed with stablesystem profile too (the difference is that it didn't got updates from unreleased errata) and doesn't have this problem so closing if there isn't an easy way how to catch the culprit |