Open newtoallofthis123 opened 7 months ago
This is an interesting case to tackle, but I reason that it would need privilege de-escalation before launching swhks since we are bound to launch swhkd
via pkexec so its children will inherit is privileges as well. what is your say
That is exactly the problem I am tackling right now 😄
pkexec
is spawning the process in sudo.
However, I am looking into ways that we can launch swhks
without the privileges. Any suggestions would be appreciated :)
This looks like a good idea but I'm not entirely sure if it is the best idea with the privilege model atm. Afaik this needs to be immediately after we are done with getting a hold of the file descriptors and then immediately after we call drop_privileges
. Maybe some other things as well, I'm not sure.
Currently, the
SWHKD
model functions on a client server architecture. Hence, the server (swhks) would have to be active through out the life span of the mainswhkd
daemon. However, this creates a user experience barrier, along with complications on the side of handling the code itself.Hence, this is a proposal to add mechanisms to start / fork the swhks server automagically during the execution of
swhkd
, if it doesn't detect the server already running. This can be easily achieved by checking theswhks.pid
file in the runtime dir.This would significantly improve the UX and the need to mention
./swhks & pkexec ./swhkd -d
would not be necessary. Moreover, this can also help the transition to a more newer privilege model.