6 Feb
2003
6 Feb
'03
10:04 a.m.
At Wed, 05 Feb 2003 13:07:59 -0500,
Paul Davis wrote:
yes, that's true.
and it's also correct that mlock() can be achieved only via root-priv
or CAP_IPC_SHM capability, unfortunately.
the merit of my library is, however, that at least the RT-priority can
be changed even with a normal kernel in a more secure way. that's
what it's for. the importance of sched_setscheduler() is bigger than
mlock() usually. but if you need really reliable operation, you must
take a root-priv.
btw, the similar mechanism can be applied to the case with
capabilities. the sched_setscheduler() and mlock() wrappers call the
helper to change the capability of the caller process (with a certain
permission check) automatically if no capapbility was given.
Takashi
i wrote a small helper library which allows
applications to change
their realtime-priority without having root privilege.
the method is similar like utempter library: the library forks and
execs the checker program which is set as setuid-root. then the
checker proves the invoking application and user (group or host) is
registered in the list, and if it's ok, changes the RT-priority of the
process. since each user and each application is tested, it's more
secure. the advantage is also that no special kernel patches are
necessary.
takashi - this isn't enough for most apps, because they need to use
mlockall(2) as well. i don't think there is anyway to get the
priviledge for this without either have an euid of 0 or have the
relevant capabilities.