On Fri, 2006-06-30 at 16:23 -0400, Al Freundorfer wrote:
> > (snip)
> >
> >
> > selinux set to enforcing:
> > remote terminal attemped login:
> > password:
> > Authentication successful.
> > Last login: Fri Jun 30 12:49:57 2006
> > /bin/bash: Permission denied
> > bash-2.03$
> >
> > /var/log/messages:
> > Jun 30 12:57:28 local kernel: audit(1151686648.208:4): enforcing=1
> > old_enforcing=0 auid=4294967295
> > Jun 30 12:58:06 local kernel: audit(1151686686.350:5): avc: denied {
> > entrypoint } for pid=2627 comm="sshd" name="bash" dev=dm-0
> > ino=49053782 scontext=user_u:system_r:amanda_t:s0
> > tcontext=system_u:object_r:shell_exec_t:s0 tclass=file
> >
> > This is a bit weird. The failures all refer to the "amanda_t" domain, which
> > is what the "amanda" backup program should run in. Nothing to do with ssh.
> > So that suggests to me that there's a labelling problem.
> >
> > However, before resorting to relabelling your system, try this:
> >
> > # setsebool -P run_ssh_inetd 1
> >
> >
> > You'll need this anyway for ssh via inetd/xinetd but I suspect it may not
> > fix the problem.
> >
> > Paul.
>
> I did as you suggested and it didn't work.
>
> How does one relabel. In the past I turned selinux off - reboot turn selinux
> on -reboot. This to me is inefficient. Is there another way?
If you disable SELinux rather than put it in permissive mode, you'll
need to do a full relabel. This has to be done during the boot process
really. It takes a long time, as you know.
Use system-config-securitylevel to put SELinux in permissive mode, then
do:
# touch /.autorelabel
# reboot
Once it has booted, the system should be labelled properly and you
shouldn't need to reboot again.
Paul.
