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. How we collect and use information is described in our Privacy Policy.