Bug 793657

btw. rmmod+modprobe of the corresponding driver changes group to this:
group::rw-

and xslaby is in group video. So this could be perfectly hidden for some time.

I think this is done by systemd-logind rules, so adding Frederic to the bug.

Frederic, can you please check, thanks!

we need :
- "loginctl" output
- "loginctl show-session X" (for each session listed in loginctl output, where X is session number).

my guess would be udev is restoring the permission to the last "active" users

Created attachment 516359 [details]
loginctl output

$ loginctl >/tmp/loginctl
$ for aa in c1 c2 c3 c4 c11; do echo =========== >>/tmp/loginctl; loginctl show-session $aa >>/tmp/loginctl;done

c11 (associated to ku) is marked as "Active", which would explain why "ku" get ACL..

*** Bug 792125 has been marked as a duplicate of this bug. ***

how did you became "ku" in the terminals ?

I've tried with su and it doesn't open a new logind session.

(In reply to comment #7)
> how did you became "ku" in the terminals ?

By:
su ku

OK, moving /etc/pam.d/common-*.rpmnew to /etc/pam.d/common-...-pc no longer adds new sessions by su. The change is mostly
[-pam_unix.so   try_first_pass-]        {+pam_unix2.so+}

and pam_env.so added to common-session.

so, not related to systemd but to pam.

Sorry, fail to see where the problem is.

You login new and the new logined user get's access.

That's the expected outcome. And that's why we have the group video.

(In reply to comment #11)
> You login new and the new logined user get's access.

I login as xslaby. Do `su ku', suspend, resume and xslaby loses an access to /dev/dvb, ability to suspend and many others.

The problem was that the newly installed pam rules were not in the common* files. They were stored as .rpmnew. Removing the .rpmnew suffix fixed the problem.

(In reply to comment #12)
> (In reply to comment #11)
> > You login new and the new logined user get's access.
> 
> I login as xslaby. Do `su ku', suspend, resume and xslaby loses an access to
> /dev/dvb, ability to suspend and many others.

Which is systemd, but not pam itself.

> The problem was that the newly installed pam rules were not in the common*
> files. They were stored as .rpmnew. Removing the .rpmnew suffix fixed the
> problem.

I'm absolute sure that there where no common-*-pc.rpmnew files, as we use pam-config and this files are not under control of RPM.

If somebody messes up in his package with other config files directly: bad for him.

Responsible for systemd session management is pam_systemd, and that's coming out of systemd ...

(In reply to comment #13)
> I'm absolute sure that there where no common-*-pc.rpmnew files, as we use
> pam-config and this files are not under control of RPM.

Right. I did
mv common-account.rpmnew common-account-pc
for all four and it works now. I have no idea where they came from...

(In reply to comment #14)
> (In reply to comment #13)
> > I'm absolute sure that there where no common-*-pc.rpmnew files, as we use
> > pam-config and this files are not under control of RPM.
> 
> Right. I did
> mv common-account.rpmnew common-account-pc
> for all four and it works now. I have no idea where they came from...

Then please provide at least a correct diff. I don't trust the comment that there was only the replacement of pam_unix.so with pam_unix2.so, I'm pretty sure that you removed pam_systemd with this action. The other two PAM modules don't have a session management at all.

> (In reply to comment #14)
> Then please provide at least a correct diff. I don't trust the comment that
> there was only the replacement of pam_unix.so with pam_unix2.so, I'm pretty
> sure that you removed pam_systemd with this action. The other two PAM modules
> don't have a session management at all.

Yes, you're right. There is a bug in colordiff which does not recognize wdiff output being over more lines. So I overlooked the change.

The wdiff outputs (I don't have -account, but it's irrelevant):
# wdiff common-session-pc common-session.rpmnew
[-#%PAM-1.0-]#
# [-This file is autogenerated by pam-config. All changes
# will be overwritten.
#
# Session-related-] {+/etc/pam.d/common-session - session-related+} modules common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of modules that define tasks to be performed
# at the start and end of sessions of *any* kind (both interactive and
# [-non-interactive-] {+non-interactive).+}
#
session required        pam_limits.so
session required        [-pam_unix2.so-]        {+pam_unix.so   try_first_pass+}
session optional        pam_umask.so
session optional        [-pam_systemd.so
session optional        pam_gnome_keyring.so    auto_start only_if=gdm,gdm-password,lxdm,lightdm-]      {+pam_env.so+}




# wdiff common-auth-pc common-auth.rpmnew |colordiff 
[-#%PAM-1.0-]#
# [-This file is autogenerated by pam-config. All changes
# will be overwritten.
#
# Authentication-related modules-] {+/etc/pam.d/common-auth - authentication settings+} common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authentication modules that define
# the central authentication scheme for use on the system
# (e.g., /etc/shadow, LDAP, Kerberos, etc.).  The default is to use the
# traditional Unix authentication mechanisms.
#
auth    required        pam_env.so
auth    [-optional      pam_gnome_keyring.so
auth-]  required        [-pam_unix2.so-]        {+pam_unix.so   try_first_pass+}





# wdiff common-password.rpmnew common-password-pc |colordiff 
{+#%PAM-1.0+}
#
# [-/etc/pam.d/common-password - password-related-] {+This file is autogenerated by pam-config. All changes
# will be overwritten.
#
# Password-related+} modules common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of modules that define  the services to be
# used to change user passwords.
#
[-# The "nullok" option allows users to change an empty password, else
# empty passwords are treated as locked accounts.
#-]
password        requisite       [-pam_cracklib.so-]     {+pam_pwcheck.so        nullok cracklib 
password        optional        pam_gnome_keyring.so    use_authtok+}

systemd is also using pam-config, so it shouldn't mess with common-account-pc file.

common-*-pc are owned by pam-config (but %ghost), so maybe at one moment in
time, rpm screwed up and created the .rpmnew file.

I guess running pam-config --force would probably have fixed the pam
configuration (but I'm not the specialist, Thorsten is)

Adding
session optional        pam_systemd.so
back to common-session-pc indeed causes `su ku' to generate a new session in loginctl output.

The files were from Nov 13th:
-rw-r--r-- 1 root root 509 13. lis 09.45 common-password.rpmnew

I don't have that old zypper logs.

That renaming the *.rpmnew file solved your problem has nothing to do with that this file exists at all, which we can ignore.

What happened: At some point the *.rpmnew file was create, for whatever reason.
Afterwards, pam_systemd.so was added with pam-config
Renaming back removed pam_systemd.so, which fixes it.
I'm pretty sure that the next systemd/pam_systemd update will re-add it again.

So the problem is the pam_systemd.so configuration, and here I cannot help. It's not my package.

I don't understand because I have a Factory up to date system, since pam_systemd present in common-session-pc and running "su alice" in a "tux" session is not creating a new session for "alice" but is "plugging" into the "parent" session"

Jiri, could you try adding debug=1 on the pam_systemd line and :
- run as root "journalctl -b -f"
- while it is running, in a terminal, "su ku"
- paste here the output of journalctl" when you logged as ku

(In reply to comment #21)
> - paste here the output of journalctl" when you logged as ku

su[22061]: (to ku) xslaby on /dev/pts/3
su[22061]: pam_unix(su:session): session opened for user ku by xslaby(uid=500)
su[22061]: pam_systemd(su:session): Asking logind to create session: uid=502 pid=22061 service=su type=tty class=...ote_host=
systemd-logind[1873]: New session c27 of user ku.

I might have a clue.

What is the value of /proc/self/loginuid before you run "su ku" and in the "su ku" session ?

(In reply to comment #23)
> What is the value of /proc/self/loginuid before you run "su ku" and in the "su
> ku" session ?

cat: /proc/self/loginuid: No such file or directory

I have auditing disabled...

could you try to enable it in your kernel ? logind relies on loginuid (not auditd) to identify sessions (and consolekit was also relying on it before IIRC).

(In reply to comment #25)
> could you try to enable it in your kernel ? logind relies on loginuid (not
> auditd) to identify sessions (and consolekit was also relying on it before
> IIRC).

Yes, enabling audit support in the kernel (thus exposing loginuid in /proc) creates no more sessions by `su'... Why systemd assumes loginuid to be present (IOW auditing to be turned on)? This requirement is invalid the same as many other assumptions systemd has :/.

you would have to ask systemd upstream ;)

closing bug as invalid, since we need audit in the kernel.

FYI, upstream has just modified logind to rely on cgroup instead of audit/loginuid to identify session in pam_systemd.

Patch is a bit too fresh to push in 12.3, but this should be fine in Factory for next upstream release of systemd