RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1468715 - mgetty-sendfax / faxrunqd, systemd and running as non-root does not play nice
Summary: mgetty-sendfax / faxrunqd, systemd and running as non-root does not play nice
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: mgetty
Version: 7.0
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Zdenek Dohnal
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks: 1534569 1636433
TreeView+ depends on / blocked
 
Reported: 2017-07-07 17:28 UTC by Gert Doering
Modified: 2019-03-26 11:22 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1636433 (view as bug list)
Environment:
Last Closed: 2019-03-26 11:22:36 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
systemd unit file for faxruqnd (340 bytes, text/plain)
2017-07-10 18:17 UTC, Gert Doering 		no flags Details
View All

Description Gert Doering 2017-07-07 17:28:53 UTC 
Description of problem:

For a real fax server, you want to run "faxrunqd" as a service (and not faxrunq from crontab) - which starts out with "there is no systemd unit file".  This needs some love :-)

Then, faxrunqd / sendfax are really intended to run as non-root - there's a "fax" user in the system, and all the spool directories belong to fax, but the device files (/dev/ttyS0) belong to "root:dialout" and the tty lock directory /var/lock/lockdev aka /run/lock/lockdev belongs to "root:lock", both not world-writeable - so, if faxrunqd/sendfax do run as user "fax", it would either be able to access the serial device, or be able to lock it, but not both at the same time.

Auxiliary groups would solve this (have "fax" belong to both "dialout" and "lock"), but as of today, "fax" is only member of the "fax" group...
 
 
Version-Release number of selected component (if applicable):
 
mgetty-1.1.36-28.el7.src.rpm
mgetty-sendfax-1.1.36-28.el7.x86_64

How reproducible:

Try to run "faxrunqd" as user fax, and send a fax to a real modem.


Steps to Reproduce:
1.
2.
3.

Actual results:

It fails locking or accessing the device, depending of the group you tell system
d to use ("Group=..." setting in the systemd service file)
 
Expected results:
 
"fax goes out"

Additional info:

I'm the upstream author, and I'm happy to help with any clarification needed.  I apologize that I'm not very well versed in using RHEL/CentOS, so anything "I should have known and checked" I might not have been aware of.  I did my best to figure out how things should be used, and that's the result...
Comment 2 Zdenek Dohnal 2017-07-10 10:54:24 UTC 
Hi Gert,

thank you for reporting this issue, but I am deeply sorry, it will not make it into RHEL 7.4 and probably I will not have enough time for this issue in RHEL-7.5 (if I'll manage to fix it, I fix it, but I cannot say now for sure).

For summarization:

1) systemd unit file is needed - we can cooperate on it, because it would be good to have systemd support for faxrunqd. We have systemd unit files for mgetty service and vgetty service, so IMO it would be good if you are able to include them into your upstream project (I mean configurable systemd support)

2) group ownership if mgetty-sendfax/faxrunqd

Is it correct?
Comment 3 Gert Doering 2017-07-10 18:17:57 UTC 
Created attachment 1295915 [details]
systemd unit file for faxruqnd

faxrunqd.service file in use here, which seems to work properly
Comment 4 Gert Doering 2017-07-10 18:22:06 UTC 
Hi,

I've attached the faxrunqd.service file that our RHEL admin has written.

I have zero experience with systemd, so I can not comment on whether it's "the right way" to do things, but I can confirm that it works and makes faxrunqd run properly as non-root user, with all the required access privileges (lock for device locking and dialout for /dev/ttyS0 access).

Given that mgetty+sendfax is developed only on systems that do not have systemd (and this is not likely to change in the near future), I cannot reasonably maintain these unit files upstream.  Sorry.
Comment 12 Zdenek Dohnal 2019-03-26 11:22:36 UTC 
Hi Kurt!

I'm deeply sorry, Red Hat Enterprise Linux version 7 is entering the Production 2 phase of its lifetime and this bug doesn't meet the criteria for it (adding new unit file is actually new feature request, which is not allowed in Production 2 phase), i.e. only high severity issues will be fixed. Please see https://access.redhat.com/support/policy/updates/errata/ for further information.

This issue is fixed in Fedora 31 (rawhide) now.
Note You need to log in before you can comment on or make changes to this bug.