The officially official Devuan Forum!

igorzwx

Member

Registered: 2024-05-06

Posts: 479  

I don't like turnstile.

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 (Yesterday 17:32:14)

ralph.ronnquist

Administrator

From: Battery Point, Tasmania, AUS

Registered: 2016-11-30

Posts: 1,600  

Re: I don't like turnstile.

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

Member

Registered: 2024-05-06

Posts: 479  

Re: I don't like turnstile.

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 (Yesterday 22:14:27)

ralph.ronnquist

Administrator

From: Battery Point, Tasmania, AUS

Registered: 2016-11-30

Posts: 1,600  

Re: I don't like turnstile.

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

Member

Registered: 2024-05-06

Posts: 479  

Re: I don't like turnstile.

"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.”