Refuse to start when SUID is detected #7044
Conversation
| return false; | ||
| } | ||
|
|
||
| sway_log(SWAY_ERROR, "SUID operation is no longer supported, refusing to start. " | ||
| "This check will be removed in a future release."); |
There was a problem hiding this comment.
Do we want to remove this check in a future release?
There was a problem hiding this comment.
The check mainly exists to avoid having people upgrade and suddenly have their existing SUID workflow turn into them suddenly running as root. After a release or two that concern should be gone.
We could leave the check in, but I also don't want to do unnecessary babysitting of users.
This ensures that those surprised by the deprecation of SUID operation receive an error rather than accidentally having sway run as root. This detection will be removed in a future release.
kennylevinsen
force-pushed
the
deprecate-suid
branch
from
4b84ab7 to
3b3742f
Compare
The split into prepare and init was pretty redundant now, so I merged prepare into |
|
Why would you refuse to start if suid rather than do whatever privileged things you need to do ( such as setting realtime scheduling priority ), then drop privileges? Not everyone can enable CAP_SYS_NICE with an EA. |
|
We do not want SUID code as it is very hard to write safely and maintain.
SUID is far too big a hammer for this. |
This ensures that those surprised by the deprecation of SUID operation
receive an error rather than accidentally having sway run as root.
This detection will be removed in a future release.