I am trying to emulate on rocky 9.4 an xinetd setup I had in CentOS 7.
An app uses the old-fashioned socket machinery to send a request on
port 10090 for program mfdraw to draw something on the screen for it.
I made socket and service files based on all the examples I could find
before asking for help here. I cannot get my mfdraw.socket to start my
mfdraw program. Here is my socket file (stored in /etc/systemd/system):
[Socket]
ListenStream=10090
Accept=yes
[Install]
WantedBy=sockets.target
And here is my template service file, also in /etc/systemd/system:
I did ‘systemctl enable mfdraw.socket’ and ‘systemctl start mfdraw.socket’.
When I run my app and it sends its startup info to port 10090, mfdraw
never gets started as proved with log and gdb tests and code in my app
prints a ‘broken socket’ error message.
‘systemctl status mfdraw.socket’ gives this:
● mfdraw.socket
Loaded: loaded (/etc/systemd/system/mfdraw.socket; enabled; preset: disabled)
Active: active (listening) since Sun 2024-06-23 21:22:42 EDT; 3 days ago
Until: Sun 2024-06-23 21:22:42 EDT; 3 days ago
Triggers: ● mfdraw@6-127.0.0.1:10090-127.0.0.1:60964.service
● mfdraw@7-127.0.0.1:10090-127.0.0.1:39304.service
● mfdraw@5-127.0.0.1:10090-127.0.0.1:49742.service
● mfdraw@4-127.0.0.1:10090-127.0.0.1:57406.service
● mfdraw@0-127.0.0.1:10090-127.0.0.1:42662.service
● mfdraw@2-::1:10090-::1:53746.service
● mfdraw@3-127.0.0.1:10090-127.0.0.1:34290.service
● mfdraw@1-::1:10090-::1:37066.service
Listen: [::]:10090 (Stream)
Accepted: 8; Connected: 0;
Tasks: 0 (limit: 98133)
Memory: 4.0K
CPU: 11ms
CGroup: /system.slice/mfdraw.socket
Apparently the ‘Triggers’ listed above are for various tests I tried.
A typical status report ‘systemctl status mfdraw@1.service’ gives this:
× mfdraw@1.service - Run mfdraw
Loaded: loaded (/etc/systemd/system/mfdraw@.service; static)
Active: failed (Result: resources)
CPU: 0
Jun 25 21:37:36 marengo4 systemd[1]: mfdraw@1.service: Got no socket.
Jun 25 21:37:36 marengo4 systemd[1]: mfdraw@1.service: Failed to run ‘start’ task: Invalid argument
Jun 25 21:37:36 marengo4 systemd[1]: mfdraw@1.service: Failed with result ‘resources’.
Jun 25 21:37:36 marengo4 systemd[1]: Failed to start Run mfdraw.
Dear James,
Of course it should be ‘/usr’. Thanks so much, I must have looked at
that 100 times.
I corrected the service file and now selinux is stopping systemd
from starting my program. I believe I can deal with that. I thought
I had disabled selinux when I installed rocky, but I guess not.
George
Before using audit2allow to create a new policy I would run audit2why first because you may be able to just enable a boolean rather than create the custom policy yourself. Also look at the actual permissions that are causing the issue, it may be better to change the security context of some files or directories than to create a new policy. All that said, I do agree that it is better to just blindly run audit2allow than it is to disable selinux.
Thanks for the suggestions re keeping selinux active. The policycoreutils was alread installed. I did ‘dnf update’ and reboot because I noted some updates relating to selinux. I made sure mfdraw (/usr/local/bin/mfdraw is just a link to it) has permissions 755, even though I asked systemd to start it with my userid and group. I ran my app that sends mfdraw startup info on port 10090. Got usual “Error reading mfdraw socket” when mfdraw’s ack did not come back. An selinux alert comes up (First screenshot) with details (second screenshot). ‘audit2why’ sits there with no output so I ctrl-c it. ‘audit2log -a /var/log/audit/audit.log’ produces output (third screenshot) that looks to me like it relates to the recent bootup, not the mfdraw exec. Any further ideas?
So in your setroubleshoot detail window you can see two commands there to resolve the problem The ausearch | audit2allow one which creates the module and then semodule to add that module and allow it to run.
Thanks again. I now have it working and am more or less happy you guys told me not to just disable selinux. To make a long story short: The suggestion in the alert to use “ausearch -c ‘(mfdraw)’ …” did not work. I did ‘setenforce 0’ and ran some more tests. There was a new alert about the program trying to use mmap() (not my code, maybe something in the plot libraries I use). I did the suggested fix ‘setsebool -P domain_can_mmap_files 1’. Now I get an alert on some read operation. The suggested fix was just like the original one, except instead of “ausearch -c ‘(mfdraw)’ …” it had “ausearch -c ‘mfdraw’ …”, i.e. the parens around ‘mfdraw’ were no longer there. I did the suggested fix this way, without the ‘-X 300’ and got a message that the old my-mfdraw module at priority 300 was overridden by the new one at priority 400. This new version worked, i.e. the app talks to mfdraw, it draws what it should, and both programs terminate normally. This can be repeated, I guess because I used the template ‘mfdraw@.service’.
So: OK, I can move on. But I like to know what I am doing, and so I am unhappy that the alerts and alert details and alert troubleshooting windows never actually told me what my program was doing that was being blocked, or what function was doing it, and I have no idea why the ‘(mfdraw)’ it told me to use was wrong and ‘mfdraw’ without the parens was OK. Comments welcome, but I will assume this thread is finished now.
George