artswrapper's new braces (Re: artswrapper defanged)

[Kevin Puetz]

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 
permissions.

How's this look for a solution? The following patch (off-the-cuff) implements 
the proposal, and reverts rikkus's unconditional disabling of realtime 
priority.

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 
welcome.

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...
Name: arts-realtime-fix.patch
Type: text/x-diff
Size: 4187 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20020807/d18b00dc/attachment.patch>