Hiya all,
After some problems the other day, I've tracked down a problem I've been having fairly definitely to selinux being on in permissive mode. sestatus shows it enabled and permissive.
Is there a way to change from permissive to disabled without rebooting? (have changed config to disabled in /etc/selinux/config, but would rather not reboot atm). setenforce 0 keeps it in this same mode as I belive thats just for enforcing mode only anyway.
Have tried googling and best I've seen is "not supported at this time" but wondering if anyone else has more hopeful info.
Thanks in advance (and to those who helped me the other day as well),
Regards, Ian
Ian mu wrote:
Hiya all,
After some problems the other day, I've tracked down a problem I've been having fairly definitely to selinux being on in permissive mode. sestatus shows it enabled and permissive.
how did you track the problem down to being a SELinux in permissive mode ?
and no, afaik, you cant move from permissive to disabled, since selinux code comes down from kernelspace.
Hiya, I tried to replicate as much of it as I could on my home pc and hit a few problems I hadn't initially thought about with selinux (it's pretty much my first experience with it, so I may be barking up the wrong tree as some of the scripts aren't mine). I can't replicate to be 100% sure, but the problems extremely similar.
Basically to test, I used sudo (as quite a few of our scripts do) with permissive on. If a shell isn't specified in a script, test.sh is just something like echo "hello" with no #!/bin/bash at first (naturally sudoers file set up).
sudo -H -u ian ./test.sh this will return with "sesh: Error execing ./test.sh: Exec format error
If I add #!/bin/bash to the start it will be fine.
I'm assuming here, the problem is with sudo using sesh and interaction with selinux. I had assumed permissive on was purely logging only and no difference in execution other than that. I'm also assuming this is by design, and not a bug (as the problem likely wouldn't be there with better designed scripts).
Naturally some problems can be got around easily by just adding the shell, but there's a few where not so simple (original problem was with cron), so was looking for a quicker fix to temp get them working by turning permissive off.
Thanks, Ian
On 10/3/06, Karanbir Singh mail-lists@karan.org wrote:
Ian mu wrote:
Hiya all,
After some problems the other day, I've tracked down a problem I've been having fairly definitely to selinux being on in permissive mode. sestatus shows it enabled and permissive.
how did you track the problem down to being a SELinux in permissive mode ?
and no, afaik, you cant move from permissive to disabled, since selinux code comes down from kernelspace.
-- Karanbir Singh : http://www.karan.org/ : 2522219@icq _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Sorry, just to clarify the main bit I missed out somehow, if I change Permissive to Disabled and don't touch the script, the script would still run fine without the exec format error.
On 10/4/06, Ian mu mu.llamas@gmail.com wrote:
Hiya, I tried to replicate as much of it as I could on my home pc and hit a few problems I hadn't initially thought about with selinux (it's pretty much my first experience with it, so I may be barking up the wrong tree as some of the scripts aren't mine). I can't replicate to be 100% sure, but the problems extremely similar.
Basically to test, I used sudo (as quite a few of our scripts do) with permissive on. If a shell isn't specified in a script, test.sh is just something like echo "hello" with no #!/bin/bash at first (naturally sudoers file set up).
sudo -H -u ian ./test.sh this will return with "sesh: Error execing ./test.sh: Exec format error
If I add #!/bin/bash to the start it will be fine.
I'm assuming here, the problem is with sudo using sesh and interaction with selinux. I had assumed permissive on was purely logging only and no difference in execution other than that. I'm also assuming this is by design, and not a bug (as the problem likely wouldn't be there with better designed scripts).
Naturally some problems can be got around easily by just adding the shell, but there's a few where not so simple (original problem was with cron), so was looking for a quicker fix to temp get them working by turning permissive off.
Thanks, Ian
On 10/3/06, Karanbir Singh mail-lists@karan.org wrote:
Ian mu wrote:
Hiya all,
After some problems the other day, I've tracked down a problem I've
been
having fairly definitely to selinux being on in permissive mode. sestatus shows it enabled and permissive.
how did you track the problem down to being a SELinux in permissive mode ?
and no, afaik, you cant move from permissive to disabled, since selinux code comes down from kernelspace.
-- Karanbir Singh : http://www.karan.org/ : 2522219@icq _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos