2 ms·
The problem is /var/lock is still used for various system root components. Which includes services like lvm2, dmraid and audio drivers. So you need at least a
by dathinab 1y ago
The problem is /var/lock is still used for various system root components.
Which includes services like lvm2, dmraid and audio drivers.
So you need at least a different /var/lock for "root" and every one else.
So you now can either fix all the root tooling to use a different lock folder. Which would break a lot of things.
Or you break a very small number of very old tools which (mostly) decided to neither use use flock (from 1996) nor follow the XDG spec (XDF_RUNTIME_DIR) from 2003.
So kinda obvious choice what way to go with ;), it just should be coordinated better and communicated better.
And yes you want quotas on tempfs on XDF_RUNTIME_DIR, without question. At least for a system more robust against misbehaving programs.
To be clear a lot of this security concerns have been irrelevant/ignored with thread models from the 2000th. But times (sadly) have changes and you shouldn't just blindly trust user space programs anymore. Even if we ignore malicious programs just thing about all the bugs AI will sneak in. And honestly I'm worried that Desktop Linux will fail to adopt to this changes. Server Linux is clearly adopting, but also more in the non-gnu Linux ecosystem while the more FSF/GNU parts of Linux seem mostly stuck in a past which doesn't look like it will have a future :/. This sucks without question but I just don't see a future without a lot of supply chain attack and AI coding induced crazy misbehavior of user space programs.
PS: Even if you just want a steam deck with the same degree of robustness as console (i.e. a game going rogue will have a hard time to hang the console fully not matter what it does, i.e. you can always press the menu button and close/kill it) you need this kind of subtle changes. And many other.
- jcalvinowens 1y ago> Which includes services like lvm2, dmraid and audio drivers. I know at least the first two have "ignore the lock" command line flags so you can get out of situations like /run being full. So whether it's a DOS depends on how you define DOS :) > it just should be coordinated better and communicated better I mean, that's the thing. I don't disagree it should be fixed. But is it really an important enough problem it justifies breaking users now? Not for me...