artswrapper's new braces (Re: artswrapper defanged)
puetzk at iastate.edu
Thu Aug 8 04:28:55 BST 2002
OK, after an IRC discussion between Phalanx, SadEagle and myself, we settled
on the following solution for realtime privs (among ourselves).
artswrapper/artsd maintain the same relationship as before, realtime is
default off but available.
artsd's existing overload detector will be expected to trap 'accidental' hangs
in trusted modules.
arts will drop RT permissions entirely if an untrusted module is loaded,
*before* executing *any* code from this module.
after some further discussion, we settled in the following definition of a
trusted module: anything represented by a .la file owned by root.
It was also proposed that the definition be 'writeable by at most root'
instead of 'owned by root', but as the latter definition is the one applied
to SUID executables, it seems the most consistent with general unix
How's this look for a solution? The following patch (off-the-cuff) implements
the proposal, and reverts rikkus's unconditional disabling of realtime
There is a (very) slight race in the checking of the permissions on the
file... however, since the permission being looked for is ownership by root,
the only user who could make anything of it is root. Since root had the right
to make the module trusted anyway, this gains no elevation of priveledge.
The other issue in question is that of a root-owned .la file pointing to
untrusted code. Since an ordinary user cannot create this exploit, and it
should not exist in any default installation (the .la files and shared
objects are created and installed at the same time, by the same user, with
the same permissions) we did not feel this was an issue. The only scenario in
which it could occur is the 'blessing' of a user .la file by root to allow
artsd to run that module with RT, which we view as a deliberate and explicit
act of trust.
One remaining issue is whether or not we should attempt to inform the user
when priority is dropped that this has occurred, and how to do so
(artsmessage? just something on stderr?). Any thoughts on this subject are
Aftre I've actually tested this fix to ensure it does what I intended it to,
if feedback is positive, I will commit.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4187 bytes
Desc: not available
More information about the kde-core-devel