* Ladislav Slezak <lslezak@suse.cz> [Aug 19. 2009 16:33]:
Dne 17.8.2009 13:36, Klaus Kaempf napsal(a):
Yes. As we're already using Ruby and ruby-dbus, its a practical way without adding new dependencies. http://kkaempf.blogspot.com/2009/02/driving-d-bus-with-ruby.html shows an example.
I see, that makes sense. Thanks for the link.
Using YaPI to leverage existing YaST functionality is the way to go. I am questioning if adding to YaPI just for WebYaST is a practical way.
I see, so we want to have the REST services YaST independent as much as possible, right?
Not quite. We want the REST service influencing existing YaST as little as possible. So keep the changes to existing yast2-* packages at a minimum. Ideally, webyast should just be an add-on, leveraging existing (YaST2-)functionality as much as possible.
[...]
Yes, but a malicious user could do ExecuteScript("start", "rm -rf /") instead of ExecuteScript("start", "/usr/bin/vendor_service")
I think this is pretty artificial. We are talking about a vendor config file specifying start/stop commands and passing those to the backend for execution. If a vendor puts "rm -rf /" in there, back luck.
Yes, that's bad, but I mean something different.
It means that the backend will execute _any_ requested script with root privileges, isn't it?
Right. However, the script path is kept completely in the backend. The unprivileged part reads the path and passes it to the privileged part (scr bash agent). So the only way to tamper is to have access to the system and hack the backend code or change the config file. I'd says we can easily live with this risk.
So we have to ensure that the DBus backend will accept requests only from webyast user so the user with custom services access rights cannot use the backend directly (e.g. via dbus-send).
Thats _exactly_ what PolicyKit is for. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org