exec_mod denial FAQ changes context of the library, but does not make this permanent across relabels. To do this, we need to use semanage to set the file context in the store. The FAQ should reflect this. Additionally, this should show both the execmod denial as well as the potential error which a user might see on the command line, like: error while loading shared libraries: /usr/lib/libavutil.so.49: cannot restore segment prot after reloc: Permission denied Original message: On Fri, 2006-04-28 at 02:11 -0700, Andrew Morton wrote: > g'day. > > - Latest FC5 > > - Get into freshrpms.net by installing > http://ftp.freshrpms.net/pub/freshrpms/fedora/linux/5/freshrpms-release/freshrpms-release-1.1-1.fc.noarch.rpm > > - yum install kino > > Now running kino gives: > > kino: error while loading shared libraries: /usr/lib/libavutil.so.49: cannot restore segment prot after reloc: Permission denied > > Did > > sony:/home/akpm# echo 0 > /selinux/enforce > sony:/home/akpm# > > and voila. > > Who do I blame? Blame the library, and file a bug against it noting that it requires a text relocation and asking them to fix it. The following information may help them understand, drawn from a comment by Ulrich Drepper in a similar bugzilla against another library: "Text relocations are the result of using position dependent code in a DSO or PIE. See http://people.redhat.com/drepper/dsohowto.pdf for explanations of building DSOs. You can hopefully easily determine what is wrong by building the binaries with debug info and then use the eu-findtextrel utility from elfutils. It should point you to the files which either are not compiled with -fpic/-fPIC or which contain assembler code which is position dependent." To allow it to proceed in the meantime while staying enforcing, you can do: # /usr/sbin/semanage fcontext -a -t textrel_shlib_t '/usr/lib/libavutil.so.[0-9]*' # /sbin/restorecon -v /usr/lib/libavutil.so.49 This tells SELinux to label the file with a type that indicates that it requires text relocation and then applies that label to it. Subsequently relabels or rpm installs/updates should then preserve it since you added it to your local file contexts via semanage. Later you can remove it with semanage fcontext -d if the library is fixed upstream. Chad, Dan - can this be added to the Fedora SELinux FAQ? I see that the FC5 SELinux FAQ does mention the use of chcon -t textrel_shlib_t, but that won't survive a relabel or package update, right? And it really needs to be in terms of the error the user will actually see (i.e. the cannot restore segment prot after reloc message), not the SELinux denial that they might not see unless they know to look in /var/log/messages or audit.log (depending on whether they are running auditd). By the way, you can also refer them to bug 187484 at bugzilla.redhat.com for reference, as that includes similar discussion for Glide and includes helpful hints like what they ended up adding to the specfile so that the package itself sets the type appropriately. But it would be preferable to eliminate the need for the text relocation, as it has both overhead and security implications (the latter is the ability to execute potentially arbitrary code due to executing from a modified private file mapping). -- Stephen Smalley FAQ version: selinux-faq-1.5.5 (2006-04-07)
Addressed in cvs