Bugzilla – Bug 437
NSC does not work when SELinux is in enforcing mode
Last modified: 2009-11-23 17:24:04 EDT
You need to log in before you can comment on or make changes to this bug.
By default, some Fedora/RedHat/CentOS systems ship with SELinux on by default. Trying to run an nsc script will produce the following error. [nsnam@ns-fedora-core-10 ns-3-dev]$ ./waf --run tcp-nsc-lfn Entering directory `/home/nsnam/hg/ns-3-dev/build' [250/250] build-nsc Compilation finished successfully /home/nsnam/hg/ns-3-dev/build/debug/liblinux2.6.26.so: cannot restore segment prot after reloc: Permission denied Command ['/home/nsnam/hg/ns-3-dev/build/debug/examples/tcp-nsc-lfn'] exited with code -11 Workaround: to temporarily disable enforcement on a running system /usr/sbin/setenforce 0 To permanently disable enforcement during a system startup change "enforcing" to "disabled" in ''/etc/selinux/config'' and reboot.
I see this is assigned to me... I have no idea what to do with this bug though. It's all working normally as far as I'm concerned!
(In reply to comment #1) > I see this is assigned to me... I have no idea what to do with this bug though. > It's all working normally as far as I'm concerned! > I don't have anything against you; Bugzilla defaults to you as the assignee for any nsc bugs (as opposed to ns-3 bugs) :) I expect that we are going to have to document this behavior and workaround, since I expect that there will be some non-negligible fraction of the user base that uses the fedora/red hat/centos variants and will see this by default when they try nsc.
adding ns-bugs to the cc list
I [personally have never seen this bug: are we sure that this is reproducible ? If so, what exact distribution versions ?
I did see this problem when it was reported. It was a permissions issue (google for "cannot restore segment prot after reloc") and there were a flurry of bug reports all over everywhere when people first started running into it as SELinux made it into 2.6 kernels. I installed ns-3 on Fedora 11 a week or so ago which does come with SELinux enabled and I can confirm that this no longer happens. I believe this was fixed in selinux-policy-targeted-1.17.30-3.9 so I took the liberty of resolving this bug as invalid (not our fault).