Yes, both executables in this case are shell scripts, so you're most likely
The original scenario seems different though, as the following conditions
are met there:
-- there is an init script with the context syslogd_initrc_exec_t, which
-- symlink under /opt/<product>/sbin which has the context of bin_t, and is
a reference for the
-- binary executable /opt/<product>/libexec/<executable> which has a
context of syslogd_exec_t.
Normally this setup works just fine, but one of our customers encountered a
situation where the daemon is stuck as initrc_t.
We have tried verifying every little detail, but we failed to spot any
differences between their environment, where the problem persists, and
ours, where everything works fine.
(*) I think, I will write a short C program in order to find out whether
this was in deed the main reason why my demo script failed to transition to
2015-05-18 20:34 GMT+02:00 Stephen Smalley <sds(a)tycho.nsa.gov>:
On 05/15/2015 04:30 AM, SZIGETVÁRI János wrote:
> Hello Again,
> I have managed to reproduce the problem on CentOS 7 as well, but due to
> the exlusion of the run_init command, the script needed a bit of
> tailoring as well.
> I have attached the modified script. (To make up for the "lost"
> run_init, the script has to have the
> "system_u:object_r:run_init_exec_t:s0" context.)
> Anyway, the problem's solution is more pressing on CentOS 6, so any help
> or hints would be appreciated.
Sorry, it looks like you are running the equivalent of:
in each of your scripts.
Which means exec bash and have it open the script file and read it, then
interpret it. So we never call execve() on the script file and thus we
never perform a domain transition. Is that what you were doing in your
original situation too?
Phone: +36209440412 (Hungary)
Make the switch to open (source) applications, protocols, formats now:
- windows -> Linux, iexplore -> Firefox, msoffice -> LibreOffice.org
- msn -> jabber protocol (Pidgin, Google Talk)
- mp3 -> ogg, wmv -> ogg, jpg -> png, doc/xls/ppt -> odt/ods/odp