> (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?
al
