Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month at the Massachusetts Institute of Technology, in Building E51.

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] Strange SELinux behavior



Looking at that command on my fedora 20 box, I see the following:
  ldd -r /usr/bin/condor_status
shows that libselinux.so is explicitly linked in to the binary.  So it 
will always try to load it.  Interestingly, there is no libsepol.so that 
gets loaded if I run it as a user or root (although that file does exist 
in /lib on my system, and SELinux is enabled).

libsepol is for manipulating the binary SELinux policies, so I'm 
guessing it probably /shouldn't/ be getting loaded by a tool like 
condor_status (unless they are trying to do something fancy like 
automatically enable a boolean for you).

Perhaps libsepol is only loaded by libselinux under certain conditions 
(i.e. using explicit calls to dlopen instead of relying on the 
startup-linking), and your user has some environment var set that 
creates those conditions?

HTH,
Matt

On 01/30/2015 10:26 AM, Richard Pieri wrote:
> Strange in that SSLinux is disabled but the run-time loader is still
> bringing libsepol.so.1 into play which leads to segfaults. What's even
> more strange is that when I run the command as root then libsepol isn't
> loaded. What am I missing?
>
> # getenforce
> Disabled
>
> $ strace condor_status
> [...]
> open("/lib/libsepol.so.1", O_RDONLY)    = 3
> read(3,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\317'\0004\0\0\0"...,
> 512) = 512
> fstat64(3, {st_mode=S_IFREG|0755, st_size=245376, ...}) = 0
> mmap2(0x27a000, 285024, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE,
> 3, 0) = 0x29c000
> mmap2(0x2d7000, 4096, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3b) = 0x2d7000
> mmap2(0x2d8000, 39264, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2d8000
> close(3)                                = 0
> mprotect(0x298000, 4096, PROT_READ)     = 0
> mprotect(0x825000, 4096, PROT_READ)     = 0
> access("/etc/selinux/", F_OK)           = 0
> open("/etc/selinux/config", O_RDONLY|O_LARGEFILE) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=511, ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0xb7de5000
> read(3, "# This file controls the state o"..., 4096) = 511
> read(3, "", 4096)                       = 0
> close(3)                                = 0
> munmap(0xb7de5000, 4096)                = 0
> open("/proc/mounts", O_RDONLY|O_LARGEFILE) = 3
> fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0xb7de5000
> read(3, "rootfs / rootfs rw 0 0\n/dev/root"..., 1024) = 800
> read(3, "", 1024)                       = 0
> close(3)                                = 0
> munmap(0xb7de5000, 4096)                = 0
> munmap(0xb7de6000, 177998)              = 0
> --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> +++ killed by SIGSEGV +++
>




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org