Staging for a rollout of EL 6, and ran into a very strange permissions issue with xinetd that defies all (my) logic.
It's a script called "spfiled" that we use for messaging between our server cluster servers. I'm trying to get it to run with "least permissions necessary". Because it reads/writes files in conjunction with a web-based service, it runs as user "apache".
Here's my xinet.d/spfiled.conf: (this is in dev, each developer has his own number) #################### spfiled.conf ################## service spfiled461 { socket_type = stream wait = no user = apache group = apache server = /path/to/filed.php protocol = tcp disable = no bind = 192.168.3.2 port = 12461 banner_fail = /path/to/banner_fail.txt cps = 10000 0 max_load = 10.0 } #################### spfiled.conf ##################
Here's the permissions of the script: # ls -laFd /path/to/filed.php -rwxr-xr-- 1 bens apache 18042 Jan 7 2011 filed.php
When I restart xinetd, I see in system log: #################### /var/log/messages ################## Jul 18 16:32:25 bender xinetd[17830]: Server /path/to/filed.php is not executable [file=/etc/xinetd.d/spfiled461] [line=11] Jul 18 16:32:25 bender xinetd[17830]: Error parsing attribute server - DISABLING SERVICE [file=/etc/xinetd.d/spfiled461] [line=11]
I've turned off SELinux completely. # setenforce 0;
Strangely, setting permissions to o+x and it starts up fine, but I don't want to leave permissions that open.
What am I missing?
2011/7/18 Benjamin Smith lists@benjamindsmith.com:
Staging for a rollout of EL 6, and ran into a very strange permissions issue with xinetd that defies all (my) logic.
It's a script called "spfiled" that we use for messaging between our server cluster servers. I'm trying to get it to run with "least permissions necessary". Because it reads/writes files in conjunction with a web-based service, it runs as user "apache".
Here's my xinet.d/spfiled.conf: (this is in dev, each developer has his own number)
#################### spfiled.conf ##################
service spfiled461
{
socket_type = stream
wait = no
user = apache
group = apache
server = /path/to/filed.php
protocol = tcp
disable = no
bind = 192.168.3.2
port = 12461
banner_fail = /path/to/banner_fail.txt
cps = 10000 0
max_load = 10.0
}
#################### spfiled.conf ##################
Here's the permissions of the script:
# ls -laFd /path/to/filed.php
-rwxr-xr-- 1 bens apache 18042 Jan 7 2011 filed.php
When I restart xinetd, I see in system log:
#################### /var/log/messages ##################
Jul 18 16:32:25 bender xinetd[17830]: Server /path/to/filed.php is not executable [file=/etc/xinetd.d/spfiled461] [line=11]
Jul 18 16:32:25 bender xinetd[17830]: Error parsing attribute server - DISABLING SERVICE [file=/etc/xinetd.d/spfiled461] [line=11]
I've turned off SELinux completely.
# setenforce 0;
Strangely, setting permissions to o+x and it starts up fine, but I don't want to leave permissions that open.
rx to owner is enought
-- Eero
On Monday, July 18, 2011 10:02:18 AM Eero Volotinen wrote:
Strangely, setting permissions to o+x and it starts up fine, but I don't want to leave permissions that open.
rx to owner is enought
Except the owner of the script is not the effective user running the script. I want to use the "x" attribute on the group account. For some reason that isn't working.
Benjamin Smith wrote:
Staging for a rollout of EL 6, and ran into a very strange permissions issue with xinetd that defies all (my) logic.
<snip> You're not using access controls lists, are you? And if this is accessed via httpd, is the php directory visible in the apache configuration?
mark
On Monday, July 18, 2011 10:20:52 AM m.roth@5-cent.us wrote:
Staging for a rollout of EL 6, and ran into a very strange permissions issue with xinetd that defies all (my) logic.
<snip> You're not using access controls lists, are you?
Not knowingly!
And if this is accessed via httpd, is the php directory visible in the apache configuration?
The data folders written by the daemon is used interchangeably with the Apache daemon (httpd) but the scripts involved are not part of the apache doc root and are not accessible via httpd.
From: Benjamin Smith lists@benjamindsmith.com
Staging for a rollout of EL 6, and ran into a very strange permissions issue with xinetd that defies all (my) logic. It's a script called "spfiled" that we use for messaging between our server cluster servers. I'm trying to get it to run with "least permissions necessary". Because it reads/writes files in conjunction with a web-based service, it runs as user "apache". ... Jul 18 16:32:25 bender xinetd[17830]: Server /path/to/filed.php is not executable [file=/etc/xinetd.d/spfiled461] [line=11] Jul 18 16:32:25 bender xinetd[17830]: Error parsing attribute server - DISABLING SERVICE [file=/etc/xinetd.d/spfiled461] [line=11]
The man page says of group: ."This attribute is ineffective if the effective user ID of xinetd is not super-user and if the groups attribute is not set to ’yes’" Xinetd running as root? Tried with groups = yes?
JD
-
Benjamin Smith -
Eero Volotinen -
John Doe -
m.roth＠5-cent.us