[systemd-devel] Is it possible to set a default for MemoryMax?
Hi there, First off, forgive me if this is documented or discussed somewhere already. I couldn't find any reference to it in the man pages or in the mailing list archives, and I'm relatively new to this community so I could easily be missing something. Context that can be skipped if you only care about the technical part of the question: We're building a customized linux environment using systemd as the init system, and we've found that some of the daemons that we're including in said environment aren't particularly good citizens in regards to their resource consumption (admittedly most of those are the ones that have been written in house). As a result, while we try to track down and fix those bugs, we would like to limit the memory that processes are allowed to consume by default (with actual values in the .service files overriding that default). While we understand that this is the sort of thing that's probably best set individually per-daemon based on an understanding of how the daemon should behave, it would at least give us a starting point and would mean that a leaky process would be the one that crashed (when it hit the memory limit), rather than taking down the whole system or the OOM killer selecting a different process that's working correctly but still happens to be using more memory at the time. We've been trying to encourage our developers to use memory accounting and MemoryMax, since we're given to understand that's applied to the entire cgroup's memory usage for a given daemon's slice. The documentation, however, doesn't seem to indicate that a default value for any of the memory variables can be set in the system.conf file, and some quick experimental testing seems to indicate that's truly the case. There does seem to be support for setting the memory resource limit (limitas), but my understanding is that wouldn't apply to subprocesses that are spawned off by the parent daemon - they'd inherit the resource limit, but get their own instance of it (and I'm actually still trying to figure out if it would apply to threads, given the way I'm given to understand Linux treats threads. For memory, it would probably still cap things, since they're all in the same address space, but I'm unclear if that would be true of the other limits that can be applied). Am I missing something and this is possible to set? Or is it something that's come up and been rejected for some reason? Or has it come up and not been important relative to other development priorities? Or has it simply never come up because we're the first ones to want to do something so foolish? Any insight that you could provide would be greatly appreciated! Thanks. -Sean McKay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] keyrings and dbus
On 13.6.2019 20.52, Simon McVittie wrote: On Thu, 13 Jun 2019 at 15:43:36 +0300, Topi Miettinen wrote: The sessions with slightly different scopes might be useful in some cases. But if this is not the case, would it be possible to unify the scopes and make systemd --user part of the login session? I don't think so. Consider these two scenarios, which I hope you'll agree should both be allowed: * ssh user@mymachine * with the ssh session still open, log in to gdm on mymachine as user * log in to gdm on mymachine as user * with the X11 or Wayland session still open, ssh user@mymachine If systemd --user is part of a login session, then in each case it would have to be started as a child process of the first way you logged in. This would result in your dbus-daemon --session and your gnome-terminal-server belonging to your ssh login session in the first scenario, and your graphical login session in the second (even though in both cases, gnome-terminal-server is drawing windows onto your graphical login session). It gets even weirder if you log out from the first login session, leaving the second one logged in, and the long-running systemd --user and dbus-daemon --session as members of a login session that no longer exists. The "user-session" concept is primarily useful when login sessions overlap like this: typically you'd have 0-1 graphical login sessions (gdm, etc.), 0 or more remote login sessions (ssh, etc.), 0 or more login sessions on a virtual console or serial console (getty/login) and 0 or more cron jobs. These are valid cases. But I think the ssh session would not actually need most of the services launched by systemd --user, like gnome-terminal-server in your example. Perhaps the answer is then not to use systemd --user, but my motivation to maximise use of systemd is that then I can use its containment features, like seccomp easily and tuned for each process, like pulseaudio and redshift. For the ssh login session, these would not be started at all (ideally) as they are useless in that login session. Or the reverse, start the login session by systemd --user? systemd --user is unprivileged and does not provide a transition from not-logged-in to logged-in state (it isn't in the same position as login, sshd, gdm, cron etc.), so it cannot start login sessions. I meant that gdm would do the privileged transition and then it would just start unprivileged systemd --user, which would launch rest of X11 setup. -Topi ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] keyrings and dbus
On Thu, 13 Jun 2019 at 15:43:36 +0300, Topi Miettinen wrote: > The sessions with slightly different scopes might be useful in some cases. > But if this is not the case, would it be possible to unify the scopes and > make systemd --user part of the login session? I don't think so. Consider these two scenarios, which I hope you'll agree should both be allowed: * ssh user@mymachine * with the ssh session still open, log in to gdm on mymachine as user * log in to gdm on mymachine as user * with the X11 or Wayland session still open, ssh user@mymachine If systemd --user is part of a login session, then in each case it would have to be started as a child process of the first way you logged in. This would result in your dbus-daemon --session and your gnome-terminal-server belonging to your ssh login session in the first scenario, and your graphical login session in the second (even though in both cases, gnome-terminal-server is drawing windows onto your graphical login session). It gets even weirder if you log out from the first login session, leaving the second one logged in, and the long-running systemd --user and dbus-daemon --session as members of a login session that no longer exists. The "user-session" concept is primarily useful when login sessions overlap like this: typically you'd have 0-1 graphical login sessions (gdm, etc.), 0 or more remote login sessions (ssh, etc.), 0 or more login sessions on a virtual console or serial console (getty/login) and 0 or more cron jobs. > Or the reverse, start the login session by systemd --user? systemd --user is unprivileged and does not provide a transition from not-logged-in to logged-in state (it isn't in the same position as login, sshd, gdm, cron etc.), so it cannot start login sessions. smcv ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Static IP address on wandering Wi-Fi client
Is there any way to tell systemd-networkd to use one .network file or another depending on which SSID the Wi-Fi interface is connected to? I've been working for a while on a router-like project that has a WAN interface which normally gets its IP address by DHCP but can be configured to use a static IP address. We've been using systemd-networkd. We recently decided to add a Wi-Fi interface as an option to the Ethernet interface, and it was easy enough to set up wpa_supplicant to handle connecting the lower layer, after which systemd-networkd uses the .network file to bring up IP, either using DHCP or a static IP address. The next issue that came up in my thinking was that a static IP address might be needed with one Wi-Fi service set, but a different static IP or DHCP service might be in play on a different service set. I don't see any way to tell systemd-networkd to use one set of parameters for one SSID but a different set for another SSID. Does this capability exist, or do I have to roll my own? (I see that NetworkManager can do this, but I really don't want to drag NetworkManager into the picture if I can avoid it.) Thanks! -- Bruce A. Johnson | Firmware Engineer Blue Ridge Networks, Inc. 14120 Parke Long Court Suite 103 | Chantilly, VA 20151 Main: 1.800.722.1168 | Direct: 703-633-7332 http://www.blueridgenetworks.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] keyrings and dbus
On 12.6.2019 22.20, Simon McVittie wrote: On Wed, 12 Jun 2019 at 19:57:39 +0300, Andrei Borzenkov wrote: 12.06.2019 19:18, Simon McVittie пишет: systemd user services are not part of a particular login session. They exist outside all login sessions (look at systemd-cgls). gnome-terminal surely *is* part of particular login session. Unfortunately it is spawned by gnome-terminal-server which itself is started as systemd user session inside sytsemd-user ... session? The gnome-terminal launcher stub (/usr/bin/gnome-terminal) is part of a particular login session, but does not persist beyond startup. All it does is to communicate with gnome-terminal-server and then exit. gnome-terminal-server exists outside the scope of any particular login session, and is the component that actually draws windows and runs a shell. This has the consequence that GNOME Terminal windows, and the shell that runs inside them, are drawn onto the X11 or Wayland display that belongs to a login session, but are not actually part of that login session. You can see this by looking at the process and cgroup hierarchies. It's your choice - but you can't have it both ways. The dbus-daemon can't be both inside a login session, and shared between login sessions. But that means that as long as there are applications that are part of user session and started by dbus-daemon, dbus-daemon simply cannot be part of systemd-user, correct? I'm very deliberately using the term "login session" because it is a jargon term identifying a specific thing in the conceptual model used by systemd-logind, which is essentially the same as the conceptual model used by non-systemd things like PAM and Linux audit. A process enters a login session in privileged code (like login(1) or gdm or similar) at the transition between "not logged in" and "logged in". All children of a process that is in a login session are in the same login session; if a process that is not in any login session starts a child process, the child is also not in any login session, unless the parent process is privileged and is deliberately starting a new login session. In systemd, a login session is represented by the session-$N.scope cgroup, where $N is the session ID. "User session" means something different: in D-Bus, we use it to refer to the collection of processes belonging to a user who currently has at least one login session. It includes all their login sessions (even if there is more than one), as well as things that belong to that user but are not in a login session, like systemd --user. In systemd, a user session is represented by the user-$UID.slice cgroup, where $UID is the user's numeric uid. systemd --user is not part of a login session. If you are starting dbus-daemon --session as a child process of systemd --user, then the definitions above mean that the dbus-daemon is not part of a login session either. The sessions with slightly different scopes might be useful in some cases. But if this is not the case, would it be possible to unify the scopes and make systemd --user part of the login session? Now it is started by PID1, but in that case it probably should be started by pam_systemd.so or more directly (e.g. /etc/X11/Xsession.d/00systemd)? Or the reverse, start the login session by systemd --user? I've tried lightly both approaches but there always seems to be some problems. -Topi ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] keyrings and dbus
On 13.06.19 12:18, Andrei Borzenkov wrote:
> 13.06.2019 11:11, Josef Moellers пишет:
>> On 12.06.19 17:34, Andrei Borzenkov wrote:
> ...
>>>
>>> If I add pam_keyinit to systemd-user, I do get session keyring for gnome
>>> terminal, but this is really wrong one:
>>>
>>> bor@10:~> cat /proc/keys
>>> 2133e406 I--Q--- 2 perm 1f3f 1000 65534 keyring _uid.1000: empty
>>> 2aeff9b2 I--Q---67 perm 3f03 1000 100 keyring _ses: 1
>>> 3c18175c I--Q---93 perm 3f03 1000 100 keyring _ses: 1
>>> bor@10:~> keyctl show -x
>>> Session Keyring
>>> 0x2aeff9b2 --alswrv 1000 100 keyring: _ses
>>> 0x2133e406 --alswrv 1000 65534 \_ keyring: _uid.1000
>>> bor@10:~>
>>
>> Not really ... if you look at the keyring IDs (in the first column) eg
>> in a gnome-terminal and in an xterm, you will see that both session
>> keyrings (the "session keyring" in the xterm and the "user session
>> keyring" in the gnome-terminal) link to the very same "user keyring":
>>
>
> I did not say "user keyring", I said "session keyring". Session keyring
> is different.
>
> bor@10:~> keyctl show -x
> Session Keyring
> 0x21a25f31 --alswrv 1000 65534 keyring: _uid_ses.1000
> 0x25f5781a --alswrv 1000 65534 \_ keyring: _uid.1000
> bor@10:~>
>
> bor@10:~> keyctl show -x
> Session Keyring
> 0x279c03fc --alswrv 1000 100 keyring: _ses
> 0x25f5781a --alswrv 1000 65534 \_ keyring: _uid.1000
> bor@10:~>
I know that. I'm still a bit unsure about how exactly these keyrings
will be used, especially how and where keys are added (they are
retrieved by searching for their description/name).
AAMOF If I log in through eg GDM or KDM or SDDM, then I get a fresh, new
session keyring to which the user keyring is linked. When I then log in
through ssh, I get a fresh, new session keyring, different from the
above, to which the user keyring (identical to the above) is linked.
The session keyrings ("_ses", the first one is a "user session keyring",
named "_uid_ses.1000") differ, but the user keyrings ("_uid.1000") are
identical.
>> Leap-15.1:
>> ssh:
>> Keyring
>> 69871887 --alswrv 1000 100 keyring: _ses
>> 105956722 --alswrv 1000 65534 \_ keyring: _uid.1000
>> -> Session Keyring (_ses) linked to User Keyring (_uid.)
>>
>> gnome-terminal(-server):
>> Keyring
>> 219457014 --alswrv 1000 65534 keyring: _uid_ses.1000
>> 105956722 --alswrv 1000 65534 \_ keyring: _uid.1000
>> -> User Session Keyring (_uid_ses.) linked to User Keyring (_uid.)
>>User Keyring is identical with User Keyring in ssh
>>
>> xterm:
>> Keyring
>> 633373159 --alswrv 1000 100 keyring: _ses
>> 105956722 --alswrv 1000 65534 \_ keyring: _uid.1000
>>
>> All three share the same "user keyring" with ID 105956722!
>> This is the single keyring the kernel maintains for the user ID 1000.
>>
>
> Your question was about session keyring, not about user keyring.
That's correct, so let's just leave the user keyrings aside, they are
identical up to the ID in all cases: only a single user keyring exists.
>>
>> TL;DR
>> The addition of "session optional pam_keyinit.so force revoke" to
>> /etc/pam.d/systemd-user seems to fix my problem.
>
> At this point I lost track what problem you solve. You still have two
> processes in user login session (graphical environment) that attach
> different session keyring.
>
> To quote:
>
> "We have seen this problem: when you open a gnome-terminal, then the
> shell in that terminal will not have the same keyring (created by
> pam_keyinit.so) as the one eg in an xterm.">
> Adding pam_keyring.so to systemd-user pam configuration does *not* fix
> it in any way.
That is correct. I was under the assumption that when I log into GNOME,
gdm obtains a session keyring ("_ses") This session keyring is then
passed on (recursively) to any process which is a descendant of that
gdm. So I would have expected that every process running within the
GNOME instance (I avoid the word "session" here) would have this session
keyring. So we were quite surprised to see that the shell inside the
gnome-terminal-server didn't. This, as we know now, is a consequence of
the fact that when you run "gnome-terminal", it doesn't fork/exec
gnome-terminal-server itself but it sends a message to systemd--user
instead which then instantiates (fork/exec?) the gnome-terminal-server.
This leads to the shell in gnome-terminal-server to have an unrelated
keyring (of some kind).
It turns out that gnome-terminal-server does not even have a keyring at
all (at least in our SUSE version of systemd) so that's why we see a
"user session keyring" rather than a "session keyring". I understand
that the upstream systemd adds a "session keyring" to each service
started by systemd--user.
Adding pam_keyring.so to systemd-user pam configuration fixes this only
so far in that gnome-terminal-server (and the bash) then have a "session
keyring".
I have had a longer internal discussion with our systemd-maintainer and
in that discussion it appeared that
Re: [systemd-devel] systemd-networkd: keeping old routes when new dhcp lease was given
Thank you for pointing this out. Unfortunately, the patch does not solve the issue. The problem does not exist on the stable version of systemd(v242). I will consider the update of it. On Tue, Jun 11, 2019 at 11:51 AM William Kennington wrote: > Probably related to this issue > https://github.com/systemd/systemd/pull/12350 > > > On Tue, Jun 11, 2019 at 02:25 Kaisrlík, Jan > wrote: > >> Hello here, >> >> I am running Yocto-thud with systemd 239 on my SoC and I've found >> interesting, when DHCP lease was prolonged, I observe the connection >> to the internet was completely stopped. >> >> Based on the logs in the system I strongly believe it is connected to >> moment when networkd renews a dhcp lease when it expires: >> >> # cat /var/log/daemon.log | grep "networkd\[" >> 2019-05-29T11:55:12.159213+00:00 x systemd-networkd[250]: Enumeration >> completed >> 2019-05-29T11:55:12.159253+00:00 x systemd-networkd[250]: lo: Link is not >> managed by us >> 2019-05-29T11:55:12.159294+00:00 x systemd-networkd[250]: veth0: netdev >> ready >> 2019-05-29T11:55:12.170082+00:00 x systemd-networkd[250]: >> request_name_destroy_callback n_ref=1 >> 2019-05-29T11:55:14.053408+00:00 x systemd-networkd[250]: eth0: Gained >> carrier >> 2019-05-29T11:55:14.058588+00:00 x systemd-networkd[250]: veth0: Gained >> carrier >> 2019-05-29T11:55:15.057317+00:00 x systemd-networkd[250]: eth0: DHCPv4 >> address 192.168.0.122/24 via 192.168.0.1 >> 2019-05-29T11:55:15.088632+00:00 x systemd-networkd[250]: veth0: Gained >> IPv6LL >> 2019-05-29T11:55:15.088833+00:00 x systemd-networkd[250]: veth0: >> Configured >> 2019-05-29T11:55:15.632514+00:00 x systemd-networkd[250]: eth0: Gained >> IPv6LL >> 2019-05-29T11:55:15.632621+00:00 x systemd-networkd[250]: eth0: Configured >> 2019-05-29T11:55:23.787104+00:00 x systemd-networkd[250]: tun0: Gained >> carrier >> 2019-05-29T11:55:23.787425+00:00 x systemd-networkd[250]: tun0: Gained >> IPv6LL >> 2019-06-03T08:27:42.019202+00:00 x systemd-networkd[250]: tun0: Lost >> carrier >> 2019-06-03T08:28:14.017067+00:00 x systemd-networkd[250]: tun0: Gained >> carrier >> 2019-06-03T08:28:14.017287+00:00 x systemd-networkd[250]: tun0: Gained >> IPv6LL >> 2019-06-04T05:27:31.261841+00:00 x systemd-networkd[250]: eth0: DHCPv4 >> address 192.168.0.125/24 via 192.168.0.1 >> 2019-06-04T08:27:56.178984+00:00 x systemd-networkd[250]: tun0: Lost >> carrier >> >> From the log above you can observe the lease was prolonged >> successfully and new ip address was given and from this particular >> moment the board was not able to connect to the internet. >> During the debugging I found this : the routes in the system are wrong >> and route with old ip address still exists in the system. >> >> # ip route >> default via 192.168.0.1 dev eth0 proto dhcp src 192.168.0.122 metric 1024 >> default via 192.168.0.1 dev eth0 proto dhcp src 192.168.0.125 metric 1024 >> 10.1.2.252/30 dev veth0 proto kernel scope link src 10.255.254.253 >> 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.125 >> 192.168.0.1 dev eth0 proto dhcp scope link src 192.168.0.122 metric 1024 >> 192.168.0.1 dev eth0 proto dhcp scope link src 192.168.0.125 metric 1024 >> >> In addition I'm adding outputs from ip tool and networkctl. >> >> # ip addr show eth0 >> 2: eth0: mtu 1500 qdisc mq state UP >> group default qlen 1000 >> link/ether e0:91:53:a3:9a:81 brd ff:ff:ff:ff:ff:ff >> inet 192.168.0.125/24 brd 192.168.0.255 scope global dynamic eth0 >>valid_lft 55210sec preferred_lft 55210sec >> inet6 fe80::e291:53ff:fea3:9a81/64 scope link >>valid_lft forever preferred_lft forever >> >> # networkctl status eth0 >> ● 2: eth0 >>Link File: /lib/systemd/network/99-default.link >> Network File: /etc/systemd/network/eth-p2p.network >> Type: ether >>State: routable (configured) >> Path: platform-ff3f.ethernet >> HW Address: e0:91:53:a3:9a:81 (XAVi Technologies Corp.) >> Address: 192.168.0.125 >> fe80::e291:53ff:fea3:9a81 >> Gateway: 192.168.0.1 (Tenda Technology Co.,Ltd.Dongguan branch) >> 192.168.0.1 (Tenda Technology Co.,Ltd.Dongguan branch) >> DNS: 192.168.0.1 >> >> What is even more interesting is the following output which does not >> fully correlate with output from ip and networkctl. >> >> # cat /run/systemd/netif/links/2 >> # This is private data. Do not parse. >> ADMIN_STATE=configured >> OPER_STATE=routable >> REQUIRED_FOR_ONLINE=yes >> NETWORK_FILE=/etc/systemd/network/eth-p2p.network >> DNS=192.168.0.1 >> NTP= >> DOMAINS= >> ROUTE_DOMAINS= >> LLMNR=yes >> MDNS=no >> ADDRESSES=192.168.0.125/24 192.168.0.122/24 >> ROUTES=192.168.0.1/32/0/1024/254/18446744073709551615 >> 0.0.0.0/0/0/1024/254/18446744073709551615 >> DHCP4_ADDRESS=192.168.0.125 >> DHCP_LEASE=/run/systemd/netif/leases/2 >> >> Unfortunately, pcaps and more verbose systemd logs are not currently >> available. >> >> Have you ever seen
Re: [systemd-devel] keyrings and dbus
13.06.2019 11:11, Josef Moellers пишет: > On 12.06.19 17:34, Andrei Borzenkov wrote: ... >> >> If I add pam_keyinit to systemd-user, I do get session keyring for gnome >> terminal, but this is really wrong one: >> >> bor@10:~> cat /proc/keys >> 2133e406 I--Q--- 2 perm 1f3f 1000 65534 keyring _uid.1000: empty >> 2aeff9b2 I--Q---67 perm 3f03 1000 100 keyring _ses: 1 >> 3c18175c I--Q---93 perm 3f03 1000 100 keyring _ses: 1 >> bor@10:~> keyctl show -x >> Session Keyring >> 0x2aeff9b2 --alswrv 1000 100 keyring: _ses >> 0x2133e406 --alswrv 1000 65534 \_ keyring: _uid.1000 >> bor@10:~> > > Not really ... if you look at the keyring IDs (in the first column) eg > in a gnome-terminal and in an xterm, you will see that both session > keyrings (the "session keyring" in the xterm and the "user session > keyring" in the gnome-terminal) link to the very same "user keyring": > I did not say "user keyring", I said "session keyring". Session keyring is different. bor@10:~> keyctl show -x Session Keyring 0x21a25f31 --alswrv 1000 65534 keyring: _uid_ses.1000 0x25f5781a --alswrv 1000 65534 \_ keyring: _uid.1000 bor@10:~> bor@10:~> keyctl show -x Session Keyring 0x279c03fc --alswrv 1000 100 keyring: _ses 0x25f5781a --alswrv 1000 65534 \_ keyring: _uid.1000 bor@10:~> > Leap-15.1: > ssh: > Keyring > 69871887 --alswrv 1000 100 keyring: _ses > 105956722 --alswrv 1000 65534 \_ keyring: _uid.1000 > -> Session Keyring (_ses) linked to User Keyring (_uid.) > > gnome-terminal(-server): > Keyring > 219457014 --alswrv 1000 65534 keyring: _uid_ses.1000 > 105956722 --alswrv 1000 65534 \_ keyring: _uid.1000 > -> User Session Keyring (_uid_ses.) linked to User Keyring (_uid.) >User Keyring is identical with User Keyring in ssh > > xterm: > Keyring > 633373159 --alswrv 1000 100 keyring: _ses > 105956722 --alswrv 1000 65534 \_ keyring: _uid.1000 > > All three share the same "user keyring" with ID 105956722! > This is the single keyring the kernel maintains for the user ID 1000. > Your question was about session keyring, not about user keyring. >> so now there are two session keyrings, some of processes (that for all >> practical purposes *do* belong to the same user session) are attached to >> one keyring, some to the other. Which makes it impossible to actually >> use session keyring to share keys. > > If keys are attached to the "user keyring", then, indeed, they can (and > will) be shared as shown above! > And? That's what you have been told from the very beginning. ... > > TL;DR > The addition of "session optional pam_keyinit.so force revoke" to > /etc/pam.d/systemd-user seems to fix my problem. At this point I lost track what problem you solve. You still have two processes in user login session (graphical environment) that attach different session keyring. To quote: "We have seen this problem: when you open a gnome-terminal, then the shell in that terminal will not have the same keyring (created by pam_keyinit.so) as the one eg in an xterm." Adding pam_keyring.so to systemd-user pam configuration does *not* fix it in any way. > The only question which > remains is if this has any adverse consequences. > You cannot use session keyring to share keys between processes that user thinks as belonging to the same (login) session. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] keyrings and dbus
On 12.06.19 17:34, Andrei Borzenkov wrote: > 11.06.2019 15:32, Josef Moellers пишет: >> On 11.06.19 13:27, Mantas Mikulėnas wrote: >>> On Tue, Jun 11, 2019 at 1:58 PM Josef Moellers > >>> The point is that in the gnome-terminal case, pam_keyinit.so is not >>> involved. >>> >>> >>> It is. The systemd --user instance (from which dbus-daemon and >>> gnome-terminal-server descend) has its own PAM stack and can call >>> pam_keyinit.so if needed. >> >> Strange thing is, that it already does! >> >> /etc/pam.d/systemd-user: >> session optional pam_keyinit.so force revoke >> > > I checked on vanilla Tumbleweed VM and systemd-user does not have > pam_keyinit. I stand corrected: I added it as part of checking whether that would help ... which it doesn't. > And yes, I observe exactly the same behavior you described. > Unfortunately things are more complicated: > > bor@10:~> cat /proc/keys > 12cf2039 I--Q---93 perm 3f03 1000 100 keyring _ses: 1 > 32af49bd I--Q--- 1 perm 1f3f 1000 65534 keyring _uid.1000: empty > bor@10:~> keyctl show -x > Session Keyring > 0x0e2f1b64 --alswrv 1000 65534 keyring: _uid_ses.1000 > 0x32af49bd --alswrv 1000 65534 \_ keyring: _uid.1000 > bor@10:~> > > > So there is user session keyring, but gnome-terminal (and any process > spawned by it) are not attached to it. > > If I add pam_keyinit to systemd-user, I do get session keyring for gnome > terminal, but this is really wrong one: > > bor@10:~> cat /proc/keys > 2133e406 I--Q--- 2 perm 1f3f 1000 65534 keyring _uid.1000: empty > 2aeff9b2 I--Q---67 perm 3f03 1000 100 keyring _ses: 1 > 3c18175c I--Q---93 perm 3f03 1000 100 keyring _ses: 1 > bor@10:~> keyctl show -x > Session Keyring > 0x2aeff9b2 --alswrv 1000 100 keyring: _ses > 0x2133e406 --alswrv 1000 65534 \_ keyring: _uid.1000 > bor@10:~> Not really ... if you look at the keyring IDs (in the first column) eg in a gnome-terminal and in an xterm, you will see that both session keyrings (the "session keyring" in the xterm and the "user session keyring" in the gnome-terminal) link to the very same "user keyring": Leap-15.1: ssh: Keyring 69871887 --alswrv 1000 100 keyring: _ses 105956722 --alswrv 1000 65534 \_ keyring: _uid.1000 -> Session Keyring (_ses) linked to User Keyring (_uid.) gnome-terminal(-server): Keyring 219457014 --alswrv 1000 65534 keyring: _uid_ses.1000 105956722 --alswrv 1000 65534 \_ keyring: _uid.1000 -> User Session Keyring (_uid_ses.) linked to User Keyring (_uid.) User Keyring is identical with User Keyring in ssh xterm: Keyring 633373159 --alswrv 1000 100 keyring: _ses 105956722 --alswrv 1000 65534 \_ keyring: _uid.1000 All three share the same "user keyring" with ID 105956722! This is the single keyring the kernel maintains for the user ID 1000. > so now there are two session keyrings, some of processes (that for all > practical purposes *do* belong to the same user session) are attached to > one keyring, some to the other. Which makes it impossible to actually > use session keyring to share keys. If keys are attached to the "user keyring", then, indeed, they can (and will) be shared as shown above! > > The first session keyring is created by gdm in this case (specifically > gdm-autologin), second - by systemd-user. What puzzles me at the moment is that I tried to reproduce this issue on my Leap 15.1 VM and IT DOES NOT REPRODUCE ANY MORE: josef@linux-7gwm:~> grep . xterm gnome-terminal xterm:Session Keyring xterm:0x1d40e70e --alswrv 1000 100 keyring: _ses xterm:0x333d487a --alswrv 1000 65534 \_ keyring: _uid.1000 gnome-terminal:Session Keyring gnome-terminal:0x3f058f6f --alswrv 1000 100 keyring: _ses gnome-terminal:0x333d487a --alswrv 1000 65534 \_ keyring: _uid.1000 Both isnatances have, at the top, a "session keyring" and none has a "user session keyring". This is due to the pam_keyring invocation I added to /etc/pam.d/systemd-user. When I remove that line (eg by commenting it out), a "user session keyring" is created instead of the "session keyring": josef@linux-7gwm:~> keyctl show -x Session Keyring 0x3ba37617 --alswrv 1000 65534 keyring: _uid_ses.1000 0x0c90f0bf --alswrv 1000 65534 \_ keyring: _uid.1000 It appears as if the "systemd --user" caches the contents of the "/etc/pam.d/systemd-user" file or maybe even runs through it only once upon startup (of systemd --user). you wouldn't know, perchance, if there are any other processes started by the "systemd --user" instance of my user? TL;DR The addition of "session optional pam_keyinit.so force revoke" to /etc/pam.d/systemd-user seems to fix my problem. The only question which remains is if this has any adverse consequences. Josef Josef -- SUSE Linux GmbH Maxfeldstrasse 5 90409 Nuernberg Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) ___ systemd-devel mailing list
