> The included cosmic-greeter.toml on Arch Linux has the following:
>
> [general]
> service = "login"
>
> This section causes my gnome keyring to not unlock automatically, and
> commenting it out makes it unlock properly - so what does this line do?

It sets the PAM service name, which in turn decides which file from 
`/etc/pam.d` to use. By default, the one named `greetd` will be used, 
whereas the pasted config will load the PAM stack intended for 
`login(1)` which in your case probably does not contain gnome keyring stuff.

Applied, thanks!

Applied, thanks!

Applied, thanks!

Applied, thanks!

(Sorry for the delay)

> Password expiry is a core posix function, and not supporting it seems
> like a gross oversight. Is this intentional?


PAM isn't POSIX, and it is not a "gross oversight". It is just a rarely 
used feature that no one seems to have had a need for so far, with other 
login managers like ly also lacking support for it. The feature predates 
any modern password recommendations, which now consider the concept of 
password expiration harmful:

- https://pages.nist.gov/800-63-FAQ/#q-b05
- 
https://learn.microsoft.com/en-us/microsoft-365/admin/misc/password-policy-recommendations?view=o365-worldwide#password-expiration-requirements-for-users
-

On 17/03/2025 06.06, zhangjide@deepin.org wrote:
> + case 's':
> + if (geteuid() != getuid()) {
> + fprintf(stderr, "-s must without setuid\n");
> + return 1;
> + }
> + unlink_existing_socket = false;
> + socket_file = optarg;
> + break;


On the previous patch I asked why you wanted to run two instances. Try 
to describe what you're trying to do, or what issue you are having.

On 14/03/2025 07.22, zhangjide@deepin.org wrote:
> The launcher can specify the socket file path using the '-s' parameter
> to avoid socket file conflicts when running multiple instances. This is
> useful for starting a privately used seatd, preventing file conflicts
> with the seatd instance started by systemd.


Hmm. The socket path flag was intentionally removed in 
0d6bdf4f01e5be10c29dd786f2531b96e1d935cd. Why did you want to run a 
second instance?

Running multiple seatd instances is not useful as they will trample on 
VT modes and try to give out access to the same device files, causing 
chaos and eavesdropping opportunities. It's also a strict security

On 04/02/2025 17.50, me@beroal.in.ua wrote:
> On the other hand, the vulnerability may be fixed with systemd and 
> greetd as described in 
> https://mastodon.social/@pid_eins/113441330932924520 . Are you 
> interested?


Not really. The way greetd currently manages login makes a greeter 
mutually exclusive with a user session, so it would mean that pressing 
the sequence would have to violently kill the active session, which I am 
not a big fan of. To avoid this it would require making greetd 
"multi-session" in such a way that it can behave as session locker and 
manage multiple ongoing user sessions, which might be a quite 
significant change that I do not currently have plans for.

> ```
> include "$HOME/.config/sway/config"
> bindsym --to-code Control+Alt+Delete exec swaymsg exit
> ```
> I hope that an attacker has no way to disable this hotkey in Sway. Am 
> I correct?


Short answer, no: the attacker could use the unbindsym command to remove 
the bindsym. The attacker would have to have sway IPC access (instead of 
Wayland IPC access), so it depends on how hardened your system is with 
respect to sandboxing. Remember that, if anything untrusted ever 
executed as your user directly outside of a sandbox, you lose - they