mirror of
https://github.com/SELinuxProject/selinux
synced 2025-03-02 16:30:36 +00:00
0b2f9ef8f3
On Sun, 2010-01-24 at 21:29 +0100, Guido Trentalancia wrote: > Hi ! > > Has anybody had any time to look at this ticket: > http://userspace.selinuxproject.org/trac/ticket/7 ? > > I have experienced the same issue and verified that the problem is actually triggered by the bzip support (as pointed out by Stephen Smalley back in August). In fact, if I use bzip-blocksize=0 in semanage.conf then the problem disappears... > > Otherwise with a default semanage.conf and bzip enabled, I get: > > libsepol.module_package_read_offsets: offset greater than file size (at 4, offset 200478 -> 8192 (No such file or directory). > libsemanage.semanage_load_module: Error while reading from module file /etc/selinux/refpolicy/modules/tmp/base.pp. (No such file or directory). > semodule: Failed! > > I am using libsepol-2.0.41 and libsemanage-2.0.42. Looking into this more closely, I believe this is another manifestation of: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543915#17 which was ultimately traced down to two issues: 1) A missing offset check in libsepol (fixed in libsepol 2.0.38), and 2) A bug / lack of binary mode support in the fmemopen implementation in glibc that was later fixed, see: http://sourceware.org/bugzilla/show_bug.cgi?id=6544 Maybe you have the older glibc still? Looking at the libsemanage code though, I think we could in fact avoid any dependency on fmemopen by using the native libsepol support for operating on a memory region via sepol_policy_file_set_mem(), ala: Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov> |
||
|---|---|---|
| checkpolicy | ||
| libselinux | ||
| libsemanage | ||
| libsepol | ||
| policycoreutils | ||
| scripts | ||
| sepolgen | ||
| .gitignore | ||
| Makefile | ||