0

I start a bash script (synchronously from java as a glassfish user) which starts a command as another user (let's say myUser):

#!/bin/bash

echo myPassword | su -c "command" myUser &

When I start this script as glassfish user from a bash shell, the command is executed immediately. But when I start this script from java, the command is executed after 10-15 seconds.

It looks like a login security timeout?

I'm wondering if this is related to SELINUX? Here is the command line to start the java program (Glassfish):

/usr/share/glassfish3/glassfish/bin/asadmin start-domain

Here is the SELINUX status of the asadmin startup script:

$ ls -Z /usr/share/glassfish3/bin/asadmin
-rwxr-xr-x. glassfish glassfish unconfined_u:object_r:bin_t:s0  /usr/share/glassfish3/bin/asadmin

I'm running : - GNU bash, version 4.2.53(1)-release (x86_64-redhat-linux-gnu) on Centos 6.4 - java 1.6.45 X86_64 and Glassfish 3.1.2.2

UPDATE: In response to @larsks comment

SeLinux is in enforcing mode. The script produces the followings audit logs when executed from java:

BEFORE THE COMMAND

type=SERVICE_START msg=audit(1438862733.335:8932): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg=' comm="fprintd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
type=USER_AVC msg=audit(1438862733.336:8933): pid=883 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc:  denied  { send_msg } for msgtype=method_return dest=:1.2520 spid=16027 tpid=16026 scontext=system_u:system_r:fprintd_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=dbus  exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'

HERE IS THE 10-15s WAIT

type=USER_AUTH msg=audit(1438862758.408:8934): pid=16026 uid=1001 auid=4294967295 ses=4294967295 subj=system_u:system_r:initrc_t:s0 msg='op=PAM:authentication acct="administrator" exe="/usr/bin/su" hostname=? addr=? terminal=? res=success'
type=USER_ACCT msg=audit(1438862758.410:8935): pid=16026 uid=1001 auid=4294967295 ses=4294967295 subj=system_u:system_r:initrc_t:s0 msg='op=PAM:accounting acct="administrator" exe="/usr/bin/su" hostname=? addr=? terminal=? res=success'
type=CRED_ACQ msg=audit(1438862758.411:8936): pid=16026 uid=1001 auid=4294967295 ses=4294967295 subj=system_u:system_r:initrc_t:s0 msg='op=PAM:setcred acct="administrator" exe="/usr/bin/su" hostname=? addr=? terminal=? res=success'
type=USER_START msg=audit(1438862758.422:8937): pid=16026 uid=1001 auid=4294967295 ses=4294967295 subj=system_u:system_r:initrc_t:s0 msg='op=PAM:session_open acct="administrator" exe="/usr/bin/su" hostname=? addr=? terminal=? res=success'
type=USER_END msg=audit(1438862758.429:8938): pid=16026 uid=1001 auid=4294967295 ses=4294967295 subj=system_u:system_r:initrc_t:s0 msg='op=PAM:session_close acct="administrator" exe="/usr/bin/su" hostname=? addr=? terminal=? res=success'
type=CRED_DISP msg=audit(1438862758.429:8939): pid=16026 uid=1001 auid=4294967295 ses=4294967295 subj=system_u:system_r:initrc_t:s0 msg='op=PAM:setcred acct="administrator" exe="/usr/bin/su" hostname=? addr=? terminal=? res=success'

NOW THE COMMAND HAS BEEN EXECUTED

The script produces the followings audit logs when executed from bash:

BEFORE THE COMMAND

type=SERVICE_START msg=audit(1438863622.854:9013): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg=' comm="fprintd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
type=USER_AUTH msg=audit(1438863622.877:9014): pid=16215 uid=1001 auid=0 ses=1116 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:authentication acct="administrator" exe="/usr/bin/su" hostname=? addr=? terminal=pts/1 res=success'
type=USER_ACCT msg=audit(1438863622.879:9015): pid=16215 uid=1001 auid=0 ses=1116 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:accounting acct="administrator" exe="/usr/bin/su" hostname=? addr=? terminal=pts/1 res=success'
type=CRED_ACQ msg=audit(1438863622.879:9016): pid=16215 uid=1001 auid=0 ses=1116 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:setcred acct="administrator" exe="/usr/bin/su" hostname=? addr=? terminal=pts/1 res=success'
type=USER_START msg=audit(1438863622.882:9017): pid=16215 uid=1001 auid=0 ses=1116 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_open acct="administrator" exe="/usr/bin/su" hostname=? addr=? terminal=pts/1 res=success'
type=USER_END msg=audit(1438863622.888:9018): pid=16215 uid=1001 auid=0 ses=1116 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_close acct="administrator" exe="/usr/bin/su" hostname=? addr=? terminal=pts/1 res=success'
type=CRED_DISP msg=audit(1438863622.888:9019): pid=16215 uid=1001 auid=0 ses=1116 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:setcred acct="administrator" exe="/usr/bin/su" hostname=? addr=? terminal=pts/1 res=success'

NOW THE COMMAND HAS BEEN EXECUTED
  • Is selinux in enforcing mode? Do you see any audit logs generated when running that command? – larsks Aug 6 '15 at 11:42
  • If I set selinux in permissive mode (via setenforce 0) the wait disappears, but it sounds like a dirty solution... – Quentin Morrier Aug 6 '15 at 12:39
  • That's odd, because there aren't any selinux denials in the audit output you've shown. If there were, you could simply craft a local selinux policy that would permit those actions, but since we don't see those denials I'm not sure what's going on. – larsks Aug 6 '15 at 12:41
  • It looks there is one denial when executed from java type=USER_AVC msg=audit(1438862733.336:8933):.. msg='avc: denied ..., which is not there when executed from bash. So you're probably right. But I'm not sure what kind of action it correspond. – Quentin Morrier Aug 6 '15 at 14:37
0

If you're getting an selinux AVC, you can set up a local policy to permit that particular action using the audit2allow tool:

# audit2allow -M local -a

This will create a policy (local.pp) that will permit anything that resulted in an selinux denial in your audit logs. You can then activate this module by running:

# semodule -i local.pp

You can see the source in the file local.te.

The AVC in your question will result in:

module local 1.0;

require {
    type fprintd_t;
    type initrc_t;
    class dbus send_msg;
}

#============= fprintd_t ==============
allow fprintd_t initrc_t:dbus send_msg;
  • Perfect! That works like a charm. Thanks a lot! Just one more precision, is there a "standart place" to store the local.te file? – Quentin Morrier Aug 7 '15 at 7:45
  • I don't think so, no. – larsks Aug 7 '15 at 11:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.