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 1322167 - [rfe] Systemd ask password clients must be run as root: should be a group to allow access
Summary: [rfe] Systemd ask password clients must be run as root: should be a group to ...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: systemd
Version: 7.2
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: systemd-maint
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks: 1316580
TreeView+ depends on / blocked
 
Reported: 2016-03-29 23:47 UTC by wibrown@redhat.com
Modified: 2019-03-04 10:41 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-03-04 08:26:55 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description wibrown@redhat.com 2016-03-29 23:47:09 UTC
Description of problem:
Systemd's ask password api for clients requires the client requesting a password to be root:

# ls -al /var/run/systemd/ask-password
total 0
drwxr-xr-x.  2 root root  40 Mar 29 15:33 .
drwxr-xr-x. 17 root root 380 Mar 29 16:19 ..

Due to the design of other applications with privilege isolation and dropping mechanisms, it can be difficult to re-architect these to request passwords as root: If anything it would be bad form.

I would like to ask that systemd creates a systemd-ask-password group for clients able to request passwords. They should be able to write to the directory /var/run/systemd/ask-password, but only root should be able to respond to the requests (Which is enforced in a number of ways already)

This would significantly improve the utility of this api: And it's required for us (Directory Server) to integrate properly with systemd-ask-password.

Thanks for your help,

Comment 2 Noriko Hosoi 2016-04-12 22:51:16 UTC
Hello,

Red Hat Directory Server has bug 1316580 which is depending upon this bug.

Currently, we have to ask the customers to run this every time the system is restarted to support the functionality, which is not acceptable.

  1) using systemctl
  # setfacl -m g:dirsrv:rwx /var/run/systemd/ask-password
    <== This is needed unless bz 1322167 is taken care by the systemd team.
  (See https://bugzilla.redhat.com/show_bug.cgi?id=1316580#c4)

Could you please fix this issue as described in #c0 or give us an advice to solve it in the better way than running setfacl?

Thanks.

Comment 3 Lukáš Nykrýn 2016-04-13 08:20:14 UTC
I am not sure if this is a good idea. But anyway, upstream first:
https://github.com/systemd/systemd/issues/3027

Comment 4 Noriko Hosoi 2016-04-13 16:23:28 UTC
Thank you for giving us the right direction, Lukáš!

#3027 has a pointer to this ticket [1], which has an interesting note:

poettering commented on Sep 18, 2015
I figure we should rework this to be based on the kernel keyring, and then support this at the same time.

* User bus breaks kernel "session" keyrings #1299 -- Closed
* RFE: extend Password Agents to user instances of systemd #2217 -- Closed
* [RFE] Systemd ask password clients must be run as root: should be a group to allow access #3027 -- Open <== Our goal.

So, it seems the kernel side tasks are done and this issue is ready to work on?

[1] https://github.com/systemd/systemd/issues/1232
Please let non-root users ask for passwords

Comment 8 Jan Synacek 2017-08-28 10:24:44 UTC
(In reply to Lukáš Nykrýn from comment #3)
> I am not sure if this is a good idea. But anyway, upstream first:
> https://github.com/systemd/systemd/issues/3027

Why not?

By the way, the upstream issue talks about implementation that uses the kernel keyring, which IMO is irrelevant to who owns /var/run/systemd/ask-password/.

Comment 9 Jan Synacek 2019-03-04 08:26:55 UTC
The upstream issue got stale and nobody really seems to care, plus this RFE is not RHEL-7 material any more.


Note You need to log in before you can comment on or make changes to this bug.