[yast-devel] WebYaST: Registration RFC
Hi, The last days I did some research about how to implement the registration in WebYaST. And the more I found out about the stuff the more complicated everthing got. I want to give a short summary and ask for your comments here. The registration itself is realised in a Perl module. There are currently two wrappers that do the workflow for this module. The first is a command line tool called "suse_register" and the second is the YaST module "inst_suse_register" which represents the GUI pendant. My first idea was to use the Perl module directly from Ruby. After a lot failures it finally works with the bindings from: http://www.yoshidam.net/Ruby.html#perl I will prepare a package of these in the BS in case somebody needs to evaluate Perl code from Ruby. When I realised that the rest-service does not run as root (it did on my workstation) but registration must run as root it made the bindings worthless. So we have to go through the needle eye of a DBus-SCR-call and run a commandline script (as root) and parse its output. Well, as I only need to call a script I don't see the need to go over DBus here. What about configuring sudo for the webservice user? Or using a tiny setuid wrapper script? Security-wise this would make no difference, as we can do everything via SCR-calls as root anyway. It would just make things less complicated (1). Fortunately I can rely on the fact that the NCC registration server (and soon SLMS as well) offer server side caching, that means, I don't need to implement a client side statemachine (which is hard in REST context where each next call is the first one). One tricky part is the zypp lock. If somebody locked the package manager on the system and then somebody else tries to register, the zypper calls will fail. The YaST module tells the user about it as it initialises the package manager on startup. But how to this in REST contect? Just return an error like "The service you are calling is temporarily not available. Please call again later"? :) This gets less funny when it happens during a registration, as we can/should not keep a package management lock in a REST service and thus the lock might be taken in the meanwhile. Ciao, Daniel -- J. Daniel Schmidt <jdsn@suse.de> SUSE Linux Products GmbH Research & Development Maxfeldstr. 5 GF: Markus Rex, HRB 16746 (AG Nürnberg) D-90409 Nürnberg (1) For me all this has too many layers already: Ok, lets skip the users browser that does HTTP(S) requests to the web-client which in turn does HTTP(S) requests to the rest-service. The rail rest-service then needs to do an SCR-DBus call which starts a DBus- Service and so does an Execute as root and runs a new script (the current suse_register is not sufficient for this) which is a new wrapper for the registration Perl module that talks to the NCC-server via HTTPS requests and parses their XML. The dumped result needs to get parsed again in the rest- service. In case there is information missing the user needs to get asked again. In case the registration is done there are (most likely) changes to be done to the package system (which might fail because of a zypp lock of a different user) that need to go there the SCR-DBus-way. Can we reduce the number of layers somehow? Or did I forget about some, that need to be added to make it more interesting? :) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
J. Daniel Schmidt schrieb:
Hi,
The last days I did some research about how to implement the registration in WebYaST. And the more I found out about the stuff the more complicated everthing got. I want to give a short summary and ask for your comments here.
The registration itself is realised in a Perl module. There are currently two wrappers that do the workflow for this module. The first is a command line tool called "suse_register" and the second is the YaST module "inst_suse_register" which represents the GUI pendant.
My first idea was to use the Perl module directly from Ruby. After a lot failures it finally works with the bindings from: http://www.yoshidam.net/Ruby.html#perl I will prepare a package of these in the BS in case somebody needs to evaluate Perl code from Ruby.
When I realised that the rest-service does not run as root (it did on my workstation) but registration must run as root it made the bindings worthless. So we have to go through the needle eye of a DBus-SCR-call and run a commandline script (as root) and parse its output.
Well, as I only need to call a script I don't see the need to go over DBus here. What about configuring sudo for the webservice user? Or using a tiny setuid wrapper script? Security-wise this would make no difference, as we can do everything via SCR-calls as root anyway. It would just make things less complicated (1).
I think we should use only one way to support script calls, cause the SCR.execute call does already some security checks while calling scripts.
Fortunately I can rely on the fact that the NCC registration server (and soon SLMS as well) offer server side caching, that means, I don't need to implement a client side statemachine (which is hard in REST context where each next call is the first one).
One tricky part is the zypp lock. If somebody locked the package manager on the system and then somebody else tries to register, the zypper calls will fail. The YaST module tells the user about it as it initialises the package manager on startup. But how to this in REST contect? Just return an error like "The service you are calling is temporarily not available. Please call again later"? :) This gets less funny when it happens during a registration, as we can/should not keep a package management lock in a REST service and thus the lock might be taken in the meanwhile.
Who generates the zypper calls and for what it is used for. Currently the "package- communication-way" of WebYaST is PackageKit. Could we use it too ? Greetings Stefan
Ciao, Daniel
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Wednesday 09 September 2009 10:36:34 Stefan Schubert wrote:
I think we should use only one way to support script calls, cause the SCR.execute call does already some security checks while calling scripts.
What security checks does SCR.execute do? Does it parse the script I want to call before it gets executed? Does it find out that my script does a "mail -s Test -a /etc/passwd"? What if it no script but a binary?
Who generates the zypper calls and for what it is used for. Currently the "package- communication-way" of WebYaST is PackageKit. Could we use it too ?
If I use the Perl script it would call zypper directly. Using the Perl module it would return a big hash with the changes that have to be done to the system. As I have to write a new wrapper script I could make it behave like the latter and let it dump the changes list. Changes to the system can be: - Add and remove services - Enable and disable catalogs (for each service) - Add and remove repositories Does PackageKit support this? Ciao, Daniel -- J. Daniel Schmidt <jdsn@suse.de> SUSE Linux Products GmbH Research & Development Maxfeldstr. 5 GF: Markus Rex, HRB 16746 (AG Nürnberg) D-90409 Nürnberg -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On 8.9.2009 18:41, J. Daniel Schmidt wrote:
Well, as I only need to call a script I don't see the need to go over DBus here. What about configuring sudo for the webservice user? Or using a tiny setuid wrapper script? Security-wise this would make no difference, as we can do everything via SCR-calls as root anyway. It would just make things less complicated (1).
Or you could create a simple YaPI wrapper (written in Perl), then you could use it over DBus the same way as the other YaST modules. I guess security team would be against any SUID wrapper... -- Best Regards Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Wednesday 09 September 2009 13:11:40 Ladislav Slezak wrote:
On 8.9.2009 18:41, J. Daniel Schmidt wrote:
Well, as I only need to call a script I don't see the need to go over DBus here. What about configuring sudo for the webservice user? Or using a tiny setuid wrapper script? Security-wise this would make no difference, as we can do everything via SCR-calls as root anyway. It would just make things less complicated (1).
Or you could create a simple YaPI wrapper (written in Perl), then you could use it over DBus the same way as the other YaST modules.
I wonder what YaPI means in this context. YaPI seems the way to go for a Perl API. If one makes a YaST module with function using the python or ruby bindings, are those exposed on dbus by YaST? -- Duncan Mac-Vicar P. - Engineering Manager, YaST SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On 9.9.2009 13:30, Duncan Mac-Vicar Prett wrote:
I wonder what YaPI means in this context. YaPI seems the way to go for a Perl API.
If one makes a YaST module with function using the python or ruby bindings, are those exposed on dbus by YaST?
Yes, they are. But YaPI provides stateless API, so it is clear that it can be safely used in WebYaST (via DBus). There is no need to call it YaPI::<something>, but IMO it makes some facts obvious... -- Best Regards Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
participants (4)
-
Duncan Mac-Vicar Prett -
J. Daniel Schmidt -
Ladislav Slezak -
Stefan Schubert