Fred, I admit that I have used the ability to run a remote script at times and have found it useful, I would be disappointed to see that functionality vanish. On the other hand I can understand the challenges of the current system.
What about the possibility of adding another configuration option in rd.conf to specify the local user / group for the RN RML to run scripts as? That way you could set up a workstation to have ripcd run those scripts as the logged in user or any other user on that system and leave the audio ownership separate. Of course it would make for one more step when setting up (you'd have to make sure the account listed actually exists on the workstation, etc), but it could potentially offer a way forward and provided it is set up correctly it would also offer a way to prevent a potentially malicious script (one that deletes the contents of /var/snd for example) from running at all. Lorne Tyndale > > > The 'Run Shell Command' ['RN'] RML has been part of Rivendell from the > early days of the project (it first appeared in v0.9.17, released on > 1/10/2005). Its use at first glance appears straightforward: run the > specified command-line invocation. However, in actual practice, it has > proven to be one of the more fussy and difficult RMLs to make work, > mostly because of the rather byzantine way in which Rivendell processes > it: send a message to the background Rivendell service (ripcd(8) to be > precise), which then handles the actual execution. In order to avoid > privilege escalation attacks, ripcd(8) actually executes the command as > the user/group specified in the 'AudioOwner=' and 'AudioGroup=' > directives in the '[Identity]' section of '/etc/rd.conf'. This has > proven in many [most?] cases to be confusing, counter-intuitive and > generally not what the user wants. > > What are some ways we could improve this RML? One that has occurred to > me is to have it run the command as the local user who actually invoked > the RML. For example, if a user is logged in to a host as 'rd' (Linux > user, *not* Rivendell user!), run the requested Linux command as user > 'rd'. > > This would have a big advantage over the current implementation in that > it does seem to be what most users intuitively expect to happen. > However, it comes with an awkward corner case: remote execution. What, > for example, would we do with an RML invocation like this: > > CC some-remote-host RN /some/dangerous/operation! > > What user/group should 'some-remote-host' run > '/some/dangerous/operation' as? The local user on the originating > system? That user may not even exist on the remote one! The current > 'locally logged in' user on 'some-remote-host'? Beyond the semantics of > exactly how one determines what 'locally logged in' means, suppose *no > one* is logged in? This is exactly why the current implementation > behaves the way it does: to resolve this ambiguity when handling remote > execution. > > Thus, if we want to make this change (execute 'RN' as the local user), > it means that we would have to give up the capability to do so remotely > --e.g. via the 'Command Send' ['CC'] RML. Would this be an acceptable > tradeoff? > > Cheers! > > > |---------------------------------------------------------------------| > | Frederick F. Gleason, Jr. | Chief Developer | > | | Paravel Systems | > |---------------------------------------------------------------------| > | Real Users never know what they want, but they always know when | > | your program doesn't deliver it. | > | | > | -- Anonymous | > |---------------------------------------------------------------------| > > _______________________________________________ > Rivendell-dev mailing list > [email protected] > http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev _______________________________________________ Rivendell-dev mailing list [email protected] http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
