Turnstile: security considerations and potential issues

igorzwx · 2026-02-09 13:01:06

One might very gently suggest that there are one or two lingering niggles about Turnstile — nothing major, mind you, more of a slight twitch of unease among the more cautious sorts.

It’s possible the word “login” itself sets off a faint, almost imperceptible alarm in certain ears — a bit like hearing the phrase “secure your bunker” during a light drizzle. Nothing to get your knickers in a twist over, but one can’t help noticing how the term does carry a certain… gravitas.

As the British might say: “Oh, it’s all perfectly fine — unless you’re the sort to worry about who’s watching the door. And the windows. And possibly the cat.”

Security Limitations and Polkit Integration

A key security limitation arises when polkit (PolicyKit) interacts with sessions managed by Turnstile.

That means things like polkit may treat anything running within turnstile as a non-local session, and may not authenticate the processes. There is no way to get around this limitation outside of patching polkit, see Chimera's patches for reference. The alternative is not registering it at all, which will not make polkit work, as the session tracking logic in it will not be able to assign the processes to any UID and things will not work either. Systemd user services are treated specially by systemd, as they are recognized by the service manager, but are explicitly not considered to be a part of any session (as they are shared); that means polkit will fall back to looking up whether any seated session for the UID exists.
_https://github.com/chimera-linux/turnstile

If pam_systemd or pam_elogind is used in the PAM configuration for Turnstile, the session may be registered without a proper seat. This causes polkit to treat the session as non-local, which can prevent proper authentication for certain operations.

Processes running within such a session may be denied privileged actions even for legitimate users.
There is no workaround without patching polkit itself, as noted in Chimera’s documentation.
Not registering the session at all leads to similar issues, as polkit cannot map processes to a UID correctly.

This creates a security-policy enforcement gap, especially in desktop environments where user privileges must be accurately determined.

Known Issues and Workarounds

Several functional and security-related issues have been reported:

Group membership not fully recognized: In some cases, tools like doas or sudo fail because secondary groups (e.g., wheel) are not properly propagated during session startup. This stems from the backend (e.g., dinit-userservd) launching services using only the UID and GID, without initializing the full group list.
DBus session exposure: Users have reported that Turnstile sometimes fails to export the DBus session environment, leading to broken user services that depend on D-Bus communication. _https://github.com/chimera-linux/turnstile/issues/2
Graphical vs. text session ambiguity: Turnstile currently cannot distinguish between graphical (e.g., X11/Wayland) and text (TTY/SSH) sessions, which limits context-aware service management.

These issues affect both usability and security, particularly in multi-user or privilege-escalation scenarios.

One could quietly observe that while the goal’s rather noble and the method quite elegant, the implementation does have a tendency to keep one busy on a Saturday evening — not in the way one might hope.

It’s not entirely undocumented, of course — more of a light suggestion of instructions, really — leaving ample room for what one might call creative troubleshooting. And as for debugging or penetration tests? Well, let’s just say they’re best approached with a sober mind, unless one enjoys chasing ghosts in the logs with a glass of something strong.

“It’s not broken — just… enthusiastically unpredictable.”

Here are the key security considerations and potential issues:

Socket Permissions and Access Control

The control socket uses permissive permissions (0666) allowing connections from non-root users turnstiled.cc:47 , but relies on platform-specific credentials checking to verify the peer's UID/GID/PID utils.cc:25-111 . This design requires proper implementation on each supported platform.

Privilege Separation

The daemon runs as root but service managers are executed with dropped privileges after proper setup exec_utils.cc:126-145
Resource limits are sanitized before PAM session setup to prevent privilege escalation exec_utils.cc:106-124

Process Management and Timeouts

Implements a 60-second timeout for service manager startup to prevent hanging logins turnstiled.cc:55 turnstiled.conf.5.scd.in:93-97
Service managers that fail to signal readiness are terminated and runtime directories are cleaned up turnstiled.cc:1043-1054

Resource Management

Runtime directories are created with proper ownership and permissions
Cleanup occurs on logout unless lingering is enabled turnstiled.cc:1071-1075

Known Limitations

When integrating with polkit, sessions may be treated as non-local
unless polkit is patched, potentially affecting authentication README.md:110-122
Root session management is disabled by default due to potential security implications turnstiled.conf.5.scd.in:99-104

Notes

The codebase appears to implement standard security practices for a session tracker, including privilege separation, credential
verification, and resource cleanup. The main security considerations are around the permissive socket permissions (mitigated by credential checking) and the polkit integration limitations.

Yes, the Turnstile daemon runs as root, as confirmed by its documentation: the daemon must be spawned as a system-wide service with superuser privileges to manage session state and launch user service managers.
While this is necessary for core functionality — such as tracking sessions, setting up XDG_RUNTIME_DIR, and spawning user services — it introduces inherent security considerations:

Running as root increases the attack surface if vulnerabilities exist in the daemon or its PAM interaction.
Although it uses a modular backend design (e.g., shell scripts to launch user services), privilege separation is minimal; the main daemon itself does not drop privileges.
There is no built-in privilege separation framework, unlike systems such as OpenSSH or systemd, which use sandboxing or process isolation.

In practice, this means trust is placed in the correctness of the code and its PAM configuration, with no fine-grained containment. As one might say:

It’s not alarming, per se — more of a "keep your fingers crossed and mind the gap" situation.

Ah, yes — having a daemon run as root is not so much a problem as it is handing the keys to the castle to a particularly excitable squirrel.

One might say:

“It’s perfectly fine — as long as you’re comfortable with the idea that if anything slightly goes awry, it won’t just trip over the rug… it’ll delete the rug, burn the house, and format the garden.”

Running as root means the daemon has full run of the system — great for trust, dreadful for security. If there’s a bug, a misconfiguration, or a slightly overambitious typo, it’s not “oops, that broke a thing” — it’s “ah, there goes the entire machine.”

And if a clever sort on the internet does manage to pop in through a crack?

“Well, they’re not exactly breaking in — more like being handed the master key, a torch, and a note saying ‘Make yourself at home.’”

So yes — it’s technically functional. But from a security standpoint?

“Let’s just say it’s not paranoid to want a bit more formality before handing over total control.”

The good news is, you can enable debugging by editing /etc/turnstile/turnstiled.conf — it’s not exactly well-documented, mind you, but it does involve flipping the debug option to yes in the config file.

# Enable verbose debug logging  
debug = yes  
  
# Also send debug messages to stderr  
debug_stderr = yes

After that, just restart the turnstiled service, and the logs should start revealing a few of its more elusive secrets.

“Nothing too alarming — just don’t be surprised if the logs start reading like a mystery novel with half the pages missing.”

While the design of Turnstile does raise a few eyebrows, it’s not so much a flaw as a deliberate bit of juggling — trading some of the usual Linux security formalities for greater flexibility in how PAM ties in.
It’s a bit like rewiring the house to take a fancy new appliance: the lights still work, but you might wonder if the fuse box is up to code.
So, one might politely ask:
“Are we quite sure we want a Linux that’s light on tradition — or have we just thrown the front door key into the garden for convenience?”

Last edited by igorzwx (2026-02-09 17:32:14)

ralph.ronnquist · 2026-02-09 21:12:51

Too much writing so it got it's own thread.

It is also the case that nothing what you raise as criticism has any value. Just very opiniated.
Turnstile does achive the notion of "user services" without comromising on security.

If you are the admin of your system, you don't need to use it, Use something else.

igorzwx · 2026-02-09 21:56:03

Your title “I don’t like turnstile” suggests a rather black-and-white take on things, doesn’t it? — as if one must choose between knowing every last detail and simply getting on with it.

It’s not entirely fair to say it’s just a trade-off between knowledge and convenience — more like a quiet agreement to stop asking awkward questions in exchange for fewer flat tyres.

“Perfectly sensible, really — so long as you don’t mind not knowing where the car’s actually going.”

Turnstile might be attractive to hackers — not because it’s weak, but because it’s sitting there with a sign saying “important things this way”.

It’s a bit like fitting a fancy lock on a shed that’s full of tools: looks secure, but also tells the thief exactly where to start looking.

So yes — it’s not a password manager, but it does run as root and handle login sessions. And if a hacker’s prowling about?

“They’d be daft not to give it a poke.”

Last edited by igorzwx (2026-02-09 22:14:27)

ralph.ronnquist · 2026-02-09 22:56:19

No, turnstile does not "handle login sessions". It gets notified about login and logout happening, and then it runs (or terminates) user scripts qua the user (not as root). I think it'd be much less of a hacker's attraction than, say, dbus, since turnstile is very well contained in what it does.

But for sure, there are many other ways for users to run programs, and there is no real need for a system to have a turnstile daemon to manage running them with "session control". I agree on that aspect

EDIT: btw, which thread title would you set?

igorzwx · 2026-02-09 23:36:55

"Turnstile: Security considerations and potential issues" might be a neutral and appropriate title.

It avoids alarmist language, doesn't assume intent or severity, and fairly signals a balanced review of possible concerns — exactly what one would expect from a technical or security assessment.

“Not dramatic, not dismissive — just a quiet invitation to have a proper look under the bonnet.”

ralph.ronnquist · 2026-02-10 00:57:17

Mmm, I give you that; though I do think your first post could be way less alarmist, if that was your intention.

igorzwx · 2026-02-10 01:44:48

Yes, it’s a bit like saying the kettle’s warm when it’s actually boiling — in Linux circles, flagging “security considerations” around a login manager isn’t just caution, it’s a quiet nod to the “don’t trust anything unless you’ve poked it with a stick” rule.

“This thing runs as root, touches logins, and isn’t covered in layers of armour. Best have a proper look under the bonnet before you let it near your front door.”

It’s not fearmongering — more a stiff upper lip way of saying:

“Assume nothing. Verify everything. Especially if it’s holding the keys.”

Downplaying security issues doesn’t calm nerves — it tends to do the opposite. People aren’t alarmed by the risks — they’re alarmed by the suggestion that someone isn’t taking them seriously. Ignoring concerns doesn’t make them vanish — it just makes people wonder what else is being ignored.

Last edited by igorzwx (2026-02-10 02:41:52)

ralph.ronnquist · 2026-02-10 03:09:17

So where did you go wrong in your study of turnstile?
It's not a login manager and it doesn't provide any root services.
Iit merely runs user scripts as user.

igorzwx · 2026-02-10 10:11:40

Here are the key security considerations and potential issues:
Socket Permissions and Access Control
The control socket uses permissive permissions (0666) allowing connections from non-root users turnstiled.cc:47 , but relies on platform-specific credentials checking to verify the peer's UID/GID/PID utils.cc:25-111 . This design requires proper implementation on each supported platform.
Privilege Separation
The daemon runs as root but service managers are executed with dropped privileges after proper setup exec_utils.cc:126-145
Resource limits are sanitized before PAM session setup to prevent privilege escalation exec_utils.cc:106-124
Process Management and Timeouts
Implements a 60-second timeout for service manager startup to prevent hanging logins turnstiled.cc:55 turnstiled.conf.5.scd.in:93-97
Service managers that fail to signal readiness are terminated and runtime directories are cleaned up turnstiled.cc:1043-1054
Resource Management
Runtime directories are created with proper ownership and permissions
Cleanup occurs on logout unless lingering is enabled turnstiled.cc:1071-1075
Known Limitations
When integrating with polkit, sessions may be treated as non-local
unless polkit is patched, potentially affecting authentication README.md:110-122
Root session management is disabled by default due to potential security implications turnstiled.conf.5.scd.in:99-104

Running as root increases the attack surface if vulnerabilities exist in the daemon or its PAM interaction.
Although it uses a modular backend design (e.g., shell scripts to launch user services), privilege separation is minimal; the main daemon itself does not drop privileges.
There is no built-in privilege separation framework, unlike systems such as OpenSSH or systemd, which use sandboxing or process isolation.
In practice, this means trust is placed in the correctness of the code and its PAM configuration, with no fine-grained containment.

Relying on the accuracy of code described by developers as a "work in progress" constitutes an unusual and risky security practice, as it introduces significant vulnerabilities due to incomplete testing, lack of peer review, and potential design flaws.
_https://github.com/chimera-linux/turnstile

The daemon needs to be running in some way. Usually you will spawn it as a system-wide service. It needs to be running as the superuser.
_https://github.com/chimera-linux/turnstile

Yes, the turnstiled deamon must run as root. This is explicitly documented and required for its core functionality.

Why Root is Required

The daemon performs privileged operations that necessitate root access:

System Directory Management: Creates directories in /run for session tracking turnstiled.cc:1276-1298
Runtime Directory Creation: Creates and chowns XDG_RUNTIME_DIR for users fs_utils.cc:55-124
Socket Operations: Binds to system paths and sets up the control socket turnstiled.cc:890-943
PAM Session Management: Establishes PAM sessions for users exec_utils.cc:316-322

Security Design

While running as root, the daemon implements:

Credential verification: Only UID 0 can create sessions turnstiled.cc:297-300
Privilege separation: Service managers run with dropped privileges exec_utils.cc:339-349
Root checks: Verifies it's running as root before privileged operations exec_utils.cc:310

The README explicitly states: "It needs to be running as the superuser" README.md:78-81 .

Notes

The daemon accepts connections via a permissive socket (0666) but enforces security through platform-specific credential checking, allowing the PAM module to communicate while maintaining access control turnstiled.cc:47 .

Any daemon running as root is inherently an attractive target for attackers. Turnstiled is no exception.

Security Reality

Turnstiled runs as root and accepts connections via a 0666 socket turnstiled.cc:47 , making it a high-value target. A compromise could allow session hijacking or privilege escalation.

Mitigations in Place

The daemon implements several security measures:

Credential verification: Every connection is authenticated using platform-specific methods (SO_PEERCRED on Linux, LOCAL_PEERCRED on BSD, etc.) utils.cc:25-111
Access control: Only UID 0 can create sessions turnstiled.cc:297-300
Privilege separation: Service managers run with dropped privileges exec_utils.cc:339-349
Resource limits: Sanitizes rlimits before PAM session setup exec_utils.cc:106-124

Attack Surface

The primary attack vectors would be:

Bugs in credential checking code
Protocol parsing vulnerabilities
Race conditions in process management
Memory corruption in the daemon

Notes

While the design is deliberate for PAM integration turnstiled.cc:40-46 , it does increase the attack surface. The security relies heavily on the correctness of the credential verification implementation. Regular security audits and keeping the daemon updated would be essential for any deployment.

The documentation does present a tension between the "work in progress" status and the security requirements.

What the Documentation States

The README explicitly labels Turnstile as "a work in progress effort" README.md:3-5 while simultaneously stating it "needs to be running as the superuser" README.md:78-81 . There is no explicit security warning about this combination.

Security Considerations in Code

The code does implement security measures:

Platform-specific credential verification for all connections
Only UID 0 can create sessions turnstiled.cc:297-300
Privilege separation for service managers

However, the design acknowledges accepting connections from non-root processes as a deliberate trade-off turnstiled.cc:40-46 .

Missing Documentation

What's absent from the documentation:

No explicit warning about running Work-In-Progress (WIP) software as root
No security audit status or review process mentioned
No clear statement about production readiness

Notes

This is a valid concern. While the code implements standard security practices for a session tracker, users should be aware that running any "work in progress" daemon as root carries inherent risks. The documentation could be more transparent about these risks and the current security posture of the project.

The project seems to place considerable faith in its users' understanding of the inherent risks involved.
The users are invited to trust developers who have not fully disclosed the security risks associated with running work-in-progress (WIP) software with root privileges.

Transparency is a key pillar of trust in software development.

In cybersecurity, trust must be earned through demonstrable actions, not assumed or invited. When developers work on software that requires elevated privileges like root access, the stakes are significantly higher. A lack of transparency about known risks, especially in Work-In-Progress (WIP) software, undermines user safety and ethical responsibility.

Transparency was, of course, something of a guiding principle in Linux and open-source software, and one rather hopes it might linger on.

Last edited by igorzwx (2026-02-12 00:43:27)

The officially official Devuan Forum!

#1 2026-02-09 13:01:06

Turnstile: security considerations and potential issues

#2 2026-02-09 21:12:51

Re: Turnstile: security considerations and potential issues

#3 2026-02-09 21:56:03

Re: Turnstile: security considerations and potential issues

#4 2026-02-09 22:56:19

Re: Turnstile: security considerations and potential issues

#5 2026-02-09 23:36:55

Re: Turnstile: security considerations and potential issues

#6 2026-02-10 00:57:17

Re: Turnstile: security considerations and potential issues

#7 2026-02-10 01:44:48

Re: Turnstile: security considerations and potential issues

#8 2026-02-10 03:09:17

Re: Turnstile: security considerations and potential issues

#9 2026-02-10 10:11:40

Re: Turnstile: security considerations and potential issues

Board footer