Bug 54176 - ExecStartPre is in a PAM session even with PermissionsStartOnly
Summary: ExecStartPre is in a PAM session even with PermissionsStartOnly
Alias: None
Product: systemd
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: All All
: medium normal
Assignee: systemd-bugs
QA Contact: systemd-bugs
Depends on:
Reported: 2012-08-29 00:01 UTC by j.witteveen
Modified: 2012-09-19 08:40 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Note You need to log in before you can comment on or make changes to this bug.
Description j.witteveen 2012-08-29 00:01:01 UTC
One of my services contains:

ExecStartPre=/usr/bin/x-daemon -nolisten tcp -noreset vt1

I noticed that the execution of the x-daemon process opens a PAM session. I feel this should not be the case: the session is for some specified user, while the script runs as root.

Changing line 1287 of src/core/execute.c to read:
err = setup_pam(apply_permissions && context->pam_name, username, uid, context->tty_path, &pam_env, fds, n_fds);
doesn't seem to do the trick. It looks like the process gets killed but the only thing I am certain of is that my system hangs.

For reference, this is the contents of the x-daemon script:

#! /bin/bash

trap "exit 0" USR1
  trap "" USR1
  exec /usr/bin/X "$@"
) &
exit 1
Comment 1 Lennart Poettering 2012-09-18 08:55:17 UTC
Fixed in git.
Comment 2 j.witteveen 2012-09-19 08:40:54 UTC
Believe it or not, but the change in Git is what I meant and tested.
I must have been very tired when copying and even editing the wrong line, here.

As I mentioned, the system locks up in the 'fixed' case. Perhaps it is not really fixed just yet.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.