BLU Discuss list archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Discuss] Strange SELinux behavior
- Subject: [Discuss] Strange SELinux behavior
- From: me at mattgillen.net (Matthew Gillen)
- Date: Fri, 30 Jan 2015 17:44:14 -0500
- In-reply-to: <54CBA288.6080308@gmail.com>
- References: <54CBA288.6080308@gmail.com>
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 +++ >
- Follow-Ups:
- [Discuss] Strange SELinux behavior
- From: richard.pieri at gmail.com (Richard Pieri)
- [Discuss] Strange SELinux behavior
- References:
- [Discuss] Strange SELinux behavior
- From: richard.pieri at gmail.com (Richard Pieri)
- [Discuss] Strange SELinux behavior
- Prev by Date: [Discuss] Strange SELinux behavior
- Next by Date: [Discuss] Strange SELinux behavior
- Previous by thread: [Discuss] Strange SELinux behavior
- Next by thread: [Discuss] Strange SELinux behavior
- Index(es):