New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please let non-root users ask for passwords #1232

Open
madduck opened this Issue Sep 10, 2015 · 9 comments

Comments

7 participants
@madduck
Copy link

madduck commented Sep 10, 2015

The file systemd-ask-password being in /bin suggests that users can use it. However, writing a service unit just now using User= to start a process as non-root exposed that /run/systemd/ask-password is not writeable by non-root.

# sudo -u backuppc env SSH_AUTH_SOCK=/run/backuppc/ssh-agent.sock DISPLAY=:0 SSH_ASKPASS=/bin/systemd-ask-password ssh-add </dev/null
Failed to create password file: Permission denied

Is there any technical reason why not anyone can register password-ask requests with the system? Ideally, the requests would get a target user such that e.g. systemd-tty-ask-password-agent can be fired off by the target users to respond to queries.

E.g., reusing the above example:

SSH_ASKPASS='/bin/systemd-ask-password -t backuppc,madduck,%backupops'

Which would create the password query and inform the given users (and members of the %bacupops group) that a password is needed, and also authorise them to provide it.

@grawity

This comment has been minimized.

Copy link
Contributor

grawity commented Sep 14, 2015

This seems useful for cronjobs.

Regarding the first part though: systemd doesn't really have a distinction between /bin and /sbin – only whether a tool is in anyone's $PATH or not at all. Especially when many tools have polkit-secured APIs, "/sbin = admin-only" makes little sense.

@madduck

This comment has been minimized.

Copy link
Author

madduck commented Sep 14, 2015

Regarding admin-only — neither does Unix. The exact and only purpose is $PATH and indirectly tab-completion.

@poettering

This comment has been minimized.

Copy link
Member

poettering commented Sep 18, 2015

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

@Firstyear

This comment has been minimized.

Copy link

Firstyear commented Apr 13, 2016

Given that sockets are authenticated, the responses can only come from root to the ask-password client. So why not make an ask-password group, that members can write to, then when they drop the socket / inf in, they can make the sck.XXXX and ask.XXXX owned as their own private uid / gid. Root still has all the access to RW the sck and the inf, other applications cannot read or write the sck and inf, or mitm it, and members of a systemd-ask-pass group can request this material without needing root.

@jsynacek

This comment has been minimized.

Copy link
Contributor

jsynacek commented Aug 16, 2017

The kernel keyring support was added in e287086.

@poettering Is there any reason why not to make /run/systemd/ask-password owned by root:ask-password or similar?

@poettering

This comment has been minimized.

Copy link
Member

poettering commented Aug 31, 2017

@poettering Is there any reason why not to make /run/systemd/ask-password owned by root:ask-password or similar?

Hmpf, I am not a fan of using UNIX groups as access check for every little facility I mus say, they are just too scarce...

@antofthy

This comment has been minimized.

Copy link

antofthy commented Oct 17, 2017

Issue is resolved with the use of the kernel keyring. Non-root users can now use "systemd-ask-password" and in fact is a great alternative method for password reading (interactive star output) from a tty.
See http://www.ict.griffith.edu.au/anthony/info/crypto/passwd_input.txt

However I have had other problems with this.

@petere

This comment has been minimized.

Copy link

petere commented Feb 21, 2018

Here is a slightly evil workaround:

ExecStartPre=+/usr/bin/setfacl -m u:someuser:wx /run/systemd/ask-password
ExecStartPost=+/usr/bin/setfacl -x u:someuser /run/systemd/ask-password

😬

@Firstyear

This comment has been minimized.

Copy link

Firstyear commented Feb 21, 2018

I have this exact work around in an officially accepted and shipped fedora/rhel package.

It's quite clear this bug will never be resolved, so please continue to hack around it with this excellent technique :D

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment