Re: SELinux-related Rawhide breakage today
Daniel J Walsh wrote: On 01/31/2012 12:07 PM, Jerry James wrote: After installing today's Rawhide updates on an x86_64 VM, I started having troubles running programs. Nothing linked with libselinux.so.1 could actually open that library; the programs were getting EACCESS on the attempt. I figured I needed to do a relabel, but since restorecon is linked with libselinux.so.1, . I touched /.autorelabel and rebooted. The system couldn't even shut down, so I had to do a sync and a forced shutoff. When the system came back up, it immediately started complaining about lots of programs that were unable to load libcrypt. So I forced it off again and rebooted with enforcing=0. That worked, but skipped the relabeling step! I got a root shell and ran restorecon by hand to relabel. The only file that got relabeled was this, which looks wrong: restorecon reset /lib64/libproc-3.2.8.so context system_u:object_r:lib_t:s0-system_u:object_r:default_t:s0 Is something broken in SELinux land today? Yes we have shipped a policy that requires the usrmove functionality. If you add /lib64 /lib to /etc/selinux/targeted/contexts/files/file_contexts.subs_dist Then run restorecon -R -v /lib64 Thanks for the heads up. I had just pulled the latest updates and found that I couldn't ssh to that box at all -- console didn't work, either. Luckily I still had the root ssh session from which I'd done the update. In it, I confirmed the /lib64 /lib line is already present in that file, presumably since I've just updated, and did this to recover: setenforce 0 restorecon -R -v /lib64 setenforce 1 Without the setenforce 0, restorecon would fail due to this: # restorecon -R -v /lib64 restorecon: error while loading shared libraries: libselinux.so.1: cannot open shared object file: No such file or directory -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinux-related Rawhide breakage today
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/01/2012 12:49 PM, Kevin Kofler wrote: Daniel J Walsh wrote: Yes we have shipped a policy that requires the usrmove functionality. How many times do we have to tell you that you MUST build usrmove stuff in the f17-usrmove build target, NOT in f17(-candidate)??? This is already the third time somebody else cleans up your mess! (Rex Dieter fixed the first offending package, I fixed the second and now Adam Williamson fixed the third.) Please build your packages in the correct tag in the first place! (fedpkg build takes a --target flag for a reason!) Kevin Kofler The first two happened at the same time. The third happened because of confusion over which is which. Thanks for your consideration. But as long as we live in the Rawhide/Non Rawhide world things are going to be strange and mistakes are going to happen. Why anyone is on Rawhide and not trying out usrmove is beyond me at this time. Rawhide is supposed to be the latest and greatest code... If we are going to do usrmove, then lets do it and get over the hump. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8pudUACgkQrlYvE4MpobMldACgtgKifrd/mWx4P93iDRAHsUfj bW0AnRyECjTzWxOuIZQq+p2sZWHW401D =Hg4k -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinux-related Rawhide breakage today
On Wed, Feb 1, 2012 at 14:16, Daniel J Walsh dwa...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 But as long as we live in the Rawhide/Non Rawhide world things are going to be strange and mistakes are going to happen. Why anyone is on Rawhide and not trying out usrmove is beyond me at this time. Rawhide is supposed to be the latest and greatest code... If we are going to do usrmove, then lets do it and get over the hump. I am on rawhide and I usually update daily (though sometimes I am on koji and update hourly to be completely insane). There are times when there is a major change when I don't update as often because I expect the change will cause problems that I don't have time to fix/troubleshoot, or know I won't be able to submit a decent bug report. There is also the need to test the next day because the fix might cause another breakage to show up. Nothing like having a fresh batch of testers. Also, thankfully, the change has not been pushed to rawhide but is available for testing elsewhere. I'm very happy that this process has started to happen for the larger changes to coordinate all the pieces that need to be in place. When the change does get moved to rawhide I'll have the decision of remaining with what I have or being part of the test at whatever state it is in. darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinux-related Rawhide breakage today
On 2012-02-01 15:16, Daniel J Walsh wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/01/2012 12:49 PM, Kevin Kofler wrote: Daniel J Walsh wrote: Yes we have shipped a policy that requires the usrmove functionality. How many times do we have to tell you that you MUST build usrmove stuff in the f17-usrmove build target, NOT in f17(-candidate)??? This is already the third time somebody else cleans up your mess! (Rex Dieter fixed the first offending package, I fixed the second and now Adam Williamson fixed the third.) Please build your packages in the correct tag in the first place! (fedpkg build takes a --target flag for a reason!) Kevin Kofler The first two happened at the same time. The third happened because of confusion over which is which. Thanks for your consideration. But as long as we live in the Rawhide/Non Rawhide world things are going to be strange and mistakes are going to happen. Why anyone is on Rawhide and not trying out usrmove is beyond me at this time. Rawhide is supposed to be the latest and greatest code... If we are going to do usrmove, then lets do it and get over the hump. There are a couple of main reasons: 1) We really didn't want the /usr move to delay Alpha testing. This one is already proving to be genuine: it's looking like we won't really be ready to push the /usr move stuff into 'production' for a day or two at least, but we can still generate working TC1 images today, since we used a tag for /usr move. 2) It was at the time (and to an extent still is) unclear whether the feature will eventually be un-approved. Providing the builds in a tag allows us to try the change out and look for previously unidentified roadblocks. If we hit something which makes us think 'crap, maybe we shouldn't do this after all', we don't have to revert and bump a ton of packages and probably cause some new problems and make things a very bumpy ride for 'regular' Rawhide users: we can just never tag the packages across to the Rawhide repo, and the change will never have happened. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinux-related Rawhide breakage today
I'll note here a nice Help wanted... If you have access to RHEL6 (or I suppose any of the binary compatible variants) and some time: rel-eng is looking for some quick regression testing of the rpm change in https://bugzilla.redhat.com/show_bug.cgi?id=761000 to make sure it doesn't break in any obvious way for all the builds we use our builders for. See: https://fedorahosted.org/fesco/ticket/690#comment:33 for more info. Basically, just setup mock with no caching, install the rpm from http://people.redhat.com/harald/downloads/rpm/4.8.0-19.el6.0.usrmove.1/ and rebuild a bunch of core packages, then check them against the normal versions. There should be no substantial differences. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
SELinux-related Rawhide breakage today
After installing today's Rawhide updates on an x86_64 VM, I started having troubles running programs. Nothing linked with libselinux.so.1 could actually open that library; the programs were getting EACCESS on the attempt. I figured I needed to do a relabel, but since restorecon is linked with libselinux.so.1, . I touched /.autorelabel and rebooted. The system couldn't even shut down, so I had to do a sync and a forced shutoff. When the system came back up, it immediately started complaining about lots of programs that were unable to load libcrypt. So I forced it off again and rebooted with enforcing=0. That worked, but skipped the relabeling step! I got a root shell and ran restorecon by hand to relabel. The only file that got relabeled was this, which looks wrong: restorecon reset /lib64/libproc-3.2.8.so context system_u:object_r:lib_t:s0-system_u:object_r:default_t:s0 Is something broken in SELinux land today? -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinux-related Rawhide breakage today
On Tue, 2012-01-31 at 14:09 -0500, Daniel J Walsh wrote: On 01/31/2012 12:07 PM, Jerry James wrote: After installing today's Rawhide updates on an x86_64 VM, I started having troubles running programs. Nothing linked with libselinux.so.1 could actually open that library; the programs were getting EACCESS on the attempt. I figured I needed to do a relabel, but since restorecon is linked with libselinux.so.1, . I touched /.autorelabel and rebooted. The system couldn't even shut down, so I had to do a sync and a forced shutoff. When the system came back up, it immediately started complaining about lots of programs that were unable to load libcrypt. So I forced it off again and rebooted with enforcing=0. That worked, but skipped the relabeling step! I got a root shell and ran restorecon by hand to relabel. The only file that got relabeled was this, which looks wrong: restorecon reset /lib64/libproc-3.2.8.so context system_u:object_r:lib_t:s0-system_u:object_r:default_t:s0 Is something broken in SELinux land today? Yes we have shipped a policy that requires the usrmove functionality. If you add /lib64 /lib to /etc/selinux/targeted/contexts/files/file_contexts.subs_dist Then run restorecon -R -v /lib64 It should fix the labeling. Not sure when usrmove is being pushed. Could you please move that build to the usr move tag so it doesn't affect all Rawhide users? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinux-related Rawhide breakage today
On Tue, 2012-01-31 at 11:19 -0800, Adam Williamson wrote: Yes we have shipped a policy that requires the usrmove functionality. If you add /lib64 /lib to /etc/selinux/targeted/contexts/files/file_contexts.subs_dist Then run restorecon -R -v /lib64 It should fix the labeling. Not sure when usrmove is being pushed. Could you please move that build to the usr move tag so it doesn't affect all Rawhide users? I've gone ahead and done this myself: selinux-policy -80 and -81 are now tagged f17-usrmove and *not* tagged f17. Otherwise I think we'd get the new selinux-policy in any F17 compose we did from now on, which would screw it up. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
