[yast-devel] Permission granularity for webyast modules
During developing my webyast modules I find, that using dbus and my YaPI quite increase amount of webyast policykit permissions. Is there any policy how detailed should be that permissions? E.g. if I have language module and for each expected features (language, utf8 and root locale) has getter and setter and getter for language list in YaPI it is 7 permissions in policy-kit. So I can change it to one read/write YaPI ( only 2 permissions) call or let it for each configuration option. josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Hi, that is a good point which I should document in Wiki: -In order not loosing the overview about the rights use granulating only if it is useful for the user/admin. -WebYaST rights and YaST-DBUS rights has to be identically in order keeping the overview. -Use rights for special values/tasks only if we can provide this single information in one request only. e.g. GET <machine>language/second_language.xml - If the YaST-DBUS interface supports this granulation and WebYaST does not we will have to "summarize" rights. For example the language module has only one GET/PUT request: GET <machine>/language.xml This returns the *complete* language information like current utf8 rootlocale ... .. . So it makes no sense for the admin who has to set the concerning rights setting each single language right for each user. He only wants to set that the user has read or write access. We can solve this by using structured name: org.opensuse.yast.modules.yapi.language.getlanguages org.opensuse.yast.modules.yapi.language.getcurrentlanguage org.opensuse.yast.modules.yapi.language.isutf8 org.opensuse.yast.modules.yapi.language.getrootlang org.opensuse.yast.modules.yapi.language.setcurrentlanguage org.opensuse.yast.modules.yapi.language.setutf8 org.opensuse.yast.modules.yapi.language.setrootlang Should become: org.opensuse.yast.modules.yapi.language.get-languages org.opensuse.yast.modules.yapi.language.get-currentlanguage org.opensuse.yast.modules.yapi.language.get-utf8 org.opensuse.yast.modules.yapi.language.get-rootlang org.opensuse.yast.modules.yapi.language.set-currentlanguage org.opensuse.yast.modules.yapi.language.set-utf8 org.opensuse.yast.modules.yapi.language.set-rootlang So we are able to generate a tree structure of the rights like get -languages -currentlanguage -utf8 -rootlang set -currentlanguage -utf8 -rootlang Which can be shown in the UI and the admin has to select the root branch "get" or "set" only in order to change the permission for all "child" rights. This will be handled by the permission rest-service of WebYaST. Any other thoughts or possibilities ? Greetings Stefan Josef Reidinger schrieb:
During developing my webyast modules I find, that using dbus and my YaPI quite increase amount of webyast policykit permissions. Is there any policy how detailed should be that permissions? E.g. if I have language module and for each expected features (language, utf8 and root locale) has getter and setter and getter for language list in YaPI it is 7 permissions in policy-kit. So I can change it to one read/write YaPI ( only 2 permissions) call or let it for each configuration option. josef
-- ******************************************************************************* Stefan Schubert SUSE LINUX GmbH - Maxfeldstrasse 5 - D-90409 Nuernberg, Germany e-mail: schubi@suse.de ------------------------------------------------------------------------------- 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
Stefan Schubert napsal(a):
Hi, that is a good point which I should document in Wiki:
-In order not loosing the overview about the rights use granulating only if it is useful for the user/admin. -WebYaST rights and YaST-DBUS rights has to be identically in order keeping the overview. -Use rights for special values/tasks only if we can provide this single information in one request only. e.g. GET <machine>language/second_language.xml - If the YaST-DBUS interface supports this granulation and WebYaST does not we will have to "summarize" rights.
For example the language module has only one GET/PUT request:
GET <machine>/language.xml
This returns the *complete* language information like current utf8 rootlocale ... .. .
This is not true for language-0.0.2, where is there only one GET/PUT, but it respect rights. So if you have rights only to read rootlocale, then you see in webclient only this one element. Same in put, where you can set only things on which you has permissions (so is valid send PUT with only rootlocale setted (I think that I forget in webclient implement disabling)). So you have only one form but object in that form is variable and depend on permission and same what element you have enabled. And get/set subtree is good idea, as it allow better structuring and also give pressure to use same standards for dbus calls (only getter and setters) which is ideal stateless interface. Also it force close setters which doesn't depend on any other call from interface. JFYI due to bug https://bugzilla.novell.com/show_bug.cgi?id=512569 is not possible to send more complex structures in dbus, even it is supported by dbus (like list of map), so some getter require some string serializing. Josef
So it makes no sense for the admin who has to set the concerning rights setting each single language right for each user. He only wants to set that the user has read or write access.
We can solve this by using structured name:
org.opensuse.yast.modules.yapi.language.getlanguages org.opensuse.yast.modules.yapi.language.getcurrentlanguage org.opensuse.yast.modules.yapi.language.isutf8 org.opensuse.yast.modules.yapi.language.getrootlang org.opensuse.yast.modules.yapi.language.setcurrentlanguage org.opensuse.yast.modules.yapi.language.setutf8 org.opensuse.yast.modules.yapi.language.setrootlang
Should become:
org.opensuse.yast.modules.yapi.language.get-languages org.opensuse.yast.modules.yapi.language.get-currentlanguage org.opensuse.yast.modules.yapi.language.get-utf8 org.opensuse.yast.modules.yapi.language.get-rootlang org.opensuse.yast.modules.yapi.language.set-currentlanguage org.opensuse.yast.modules.yapi.language.set-utf8 org.opensuse.yast.modules.yapi.language.set-rootlang
So we are able to generate a tree structure of the rights like get -languages -currentlanguage -utf8 -rootlang set -currentlanguage -utf8 -rootlang
Which can be shown in the UI and the admin has to select the root branch "get" or "set" only in order to change the permission for all "child" rights. This will be handled by the permission rest-service of WebYaST.
Any other thoughts or possibilities ?
Greetings Stefan
Josef Reidinger schrieb:
During developing my webyast modules I find, that using dbus and my YaPI quite increase amount of webyast policykit permissions. Is there any policy how detailed should be that permissions? E.g. if I have language module and for each expected features (language, utf8 and root locale) has getter and setter and getter for language list in YaPI it is 7 permissions in policy-kit. So I can change it to one read/write YaPI ( only 2 permissions) call or let it for each configuration option. josef
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
josef reidinger schrieb:
Stefan Schubert napsal(a):
Hi, that is a good point which I should document in Wiki:
-In order not loosing the overview about the rights use granulating only if it is useful for the user/admin. -WebYaST rights and YaST-DBUS rights has to be identically in order keeping the overview. -Use rights for special values/tasks only if we can provide this single information in one request only. e.g. GET <machine>language/second_language.xml - If the YaST-DBUS interface supports this granulation and WebYaST does not we will have to "summarize" rights.
For example the language module has only one GET/PUT request:
GET <machine>/language.xml
This returns the *complete* language information like current utf8 rootlocale ... .. .
This is not true for language-0.0.2, where is there only one GET/PUT,
Ah, ok you have changed it while my vacation :-) . It looks nice. The general question here is if it is really needed to give rights for each field.
but it respect rights. So if you have rights only to read rootlocale, then you see in webclient only this one element. Same in put, where you can set only things on which you has permissions (so is valid send PUT with only rootlocale setted (I think that I forget in webclient implement disabling)). So you have only one form but object in that form is variable and depend on permission and same what element you have enabled. And get/set subtree is good idea, as it allow better structuring and also give pressure to use same standards for dbus calls (only getter and setters) which is ideal stateless interface. Also it force close setters which doesn't depend on any other call from interface. JFYI due to bug https://bugzilla.novell.com/show_bug.cgi?id=512569 is not possible to send more complex structures in dbus, even it is supported by dbus (like list of map), so some getter require some string serializing. Josef
-- ******************************************************************************* Stefan Schubert SUSE LINUX GmbH - Maxfeldstrasse 5 - D-90409 Nuernberg, Germany e-mail: schubi@suse.de ------------------------------------------------------------------------------- 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
josef reidinger wrote:
JFYI due to bug https://bugzilla.novell.com/show_bug.cgi?id=512569 is not possible to send more complex structures in dbus, even it is supported by dbus (like list of map), so some getter require some string serializing.
Fixed in yast2-core-2.18.13 - give it a try, I had to refactor relatively large part of YCP->DBus data conversion. (YCPMap type check has been removed (not needed, copy&paste bug), nested structures like map or list were handled in a wrong way.) -- 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
Ladislav Slezak wrote:
josef reidinger wrote:
JFYI due to bug https://bugzilla.novell.com/show_bug.cgi?id=512569 is not possible to send more complex structures in dbus, even it is supported by dbus (like list of map), so some getter require some string serializing.
Fixed in yast2-core-2.18.13 - give it a try, I had to refactor relatively large part of YCP->DBus data conversion.
(YCPMap type check has been removed (not needed, copy&paste bug), nested structures like map or list were handled in a wrong way.)
Tested and works for me, thanks -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Stefan Schubert wrote:
Which can be shown in the UI and the admin has to select the root branch "get" or "set" only in order to change the permission for all "child" rights. This will be handled by the permission rest-service of WebYaST.
Any other thoughts or possibilities ?
What about using . (dot) as a separator? E.g. org.opensuse.yast.modules.yapi.language.get.languages The Yast DBus service replaces :: in the name by a single dot when generating the respective PolicyKit action: YaPI::LANGUAGE::Get::Languages() function is mapped to org.opensuse.yast.modules.yapi.language.get.languages PolicyKit action. -- 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
Ladislav Slezak schrieb:
Stefan Schubert wrote:
Which can be shown in the UI and the admin has to select the root branch "get" or "set" only in order to change the permission for all "child" rights. This will be handled by the permission rest-service of WebYaST.
Any other thoughts or possibilities ?
What about using . (dot) as a separator? E.g. org.opensuse.yast.modules.yapi.language.get.languages
In former versions of WebYaST I have tried out "." without success :-( So I assume that this is not supported on DBUS/Polkit level. I would also prefer dots. Could anyone try it out again please ? Perhaps I have made a mistake or it is fixed in Polkit now.... Greetings Stefan -- ******************************************************************************* Stefan Schubert SUSE LINUX GmbH - Maxfeldstrasse 5 - D-90409 Nuernberg, Germany e-mail: schubi@suse.de ------------------------------------------------------------------------------- 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
On Mon, Jun 15, 2009 at 12:10:12PM +0200, Stefan Schubert wrote:
So it makes no sense for the admin who has to set the concerning rights setting each single language right for each user. He only wants to set that the user has read or write access.
We can solve this by using structured name:
org.opensuse.yast.modules.yapi.language.getlanguages org.opensuse.yast.modules.yapi.language.getcurrentlanguage
Should become:
org.opensuse.yast.modules.yapi.language.get-languages org.opensuse.yast.modules.yapi.language.get-currentlanguage
So we are able to generate a tree structure of the rights like get -languages -currentlanguage
Which can be shown in the UI and the admin has to select the root branch "get" or "set" only in order to change the permission for all "child" rights. This will be handled by the permission rest-service of WebYaST.
So you're introducing a regrouping of the action ID, by dashes instead of by dots. I actually thought that it was a bug, so I fixed it in the webclient: http://git.opensuse.org/?p=projects/yast/web-client.git;a=commitdiff;h=c9af4... I think that it is a futile attempt to overcome the initial problem of having too many permissions to deal with. How about removing them instead? That means not having the complete "API" of YaST accessible via DBus, but it is not a real API anyway. Instead, we should build the API to fit the permissions. -- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Martin Vidner schrieb:
On Mon, Jun 15, 2009 at 12:10:12PM +0200, Stefan Schubert wrote:
So it makes no sense for the admin who has to set the concerning rights setting each single language right for each user. He only wants to set that the user has read or write access.
We can solve this by using structured name:
org.opensuse.yast.modules.yapi.language.getlanguages org.opensuse.yast.modules.yapi.language.getcurrentlanguage
Should become:
org.opensuse.yast.modules.yapi.language.get-languages org.opensuse.yast.modules.yapi.language.get-currentlanguage
So we are able to generate a tree structure of the rights like get -languages -currentlanguage
Which can be shown in the UI and the admin has to select the root branch "get" or "set" only in order to change the permission for all "child" rights. This will be handled by the permission rest-service of WebYaST.
So you're introducing a regrouping of the action ID, by dashes instead of by dots.
I actually thought that it was a bug, so I fixed it in the webclient: http://git.opensuse.org/?p=projects/yast/web-client.git;a=commitdiff;h=c9af4...
Ähm, that was intent as I described in an EMAIL before. As far I remember I have had problems with the polkit-auth command while setting these single permissions separated by dots. I believe that it has to do with polkit-filename which describes the rights.
I think that it is a futile attempt to overcome the initial problem of having too many permissions to deal with.
Thats my main aim to reduce the amount of permissions :-)
How about removing them instead? That means not having the complete "API" of YaST accessible via DBus, but it is not a real API anyway. Instead, we should build the API to fit the permissions.
My intention is to have one permission file for the REST AND the DBUS interface. Thats why I would like to use this tree structure in order to make it simple. Greetings Stefan -- ******************************************************************************* Stefan Schubert SUSE LINUX GmbH - Maxfeldstrasse 5 - D-90409 Nuernberg, Germany e-mail: schubi@suse.de ------------------------------------------------------------------------------- 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
On Mon, Jun 15, 2009 at 01:14:08PM +0200, Stefan Schubert wrote:
Martin Vidner schrieb:
I think that it is a futile attempt to overcome the initial problem of having too many permissions to deal with.
Thats my main aim to reduce the amount of permissions :-)
How about removing them instead? That means not having the complete "API" of YaST accessible via DBus, but it is not a real API anyway. Instead, we should build the API to fit the permissions.
My intention is to have one permission file for the REST AND the DBUS interface. Thats why I would like to use this tree structure in order to make it simple.
Can't you see? You are not removing them, only hiding. It is good if you want to unify the permission files for the two layers. But it is the wrong way around if you take the existing non-API and create the permissions from that, because that floods the admin with detail, which is not well designed anyway. -- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Martin Vidner schrieb:
On Mon, Jun 15, 2009 at 01:14:08PM +0200, Stefan Schubert wrote:
Martin Vidner schrieb:
I think that it is a futile attempt to overcome the initial problem of having too many permissions to deal with.
Thats my main aim to reduce the amount of permissions :-)
How about removing them instead? That means not having the complete "API" of YaST accessible via DBus, but it is not a real API anyway. Instead, we should build the API to fit the permissions.
My intention is to have one permission file for the REST AND the DBUS interface. Thats why I would like to use this tree structure in order to make it simple.
Hey, I am older than you. So please forgive me if takes a little bit longer until I am understanding or having an overview :-)
Can't you see? You are not removing them, only hiding.
Yes, "hiding" that is the point and that's why we should use the tree structure and showing not all sub branches (default) but almost root branches like language/get language/set only. If the admin is interested in more details he can show the subtrees too. (The question if granulated permissions are need at all in the language module has already been discussed). I know, that is a compromise but it prevents us for defining a new configuration file with which the "hiding rules" are defined.
It is good if you want to unify the permission files for the two layers. But it is the wrong way around if you take the existing non-API and create the permissions from that, because that floods the admin with detail, which is not well designed anyway.
Fully agree. But here comes the question why it is not well designed and why there is so much different between the YaST-DBUS interface and the YaST-REST interface which is described in the policies too ? From my point of view the YaST-Webservice should only be a wrapper which transforms the YaST-DBUS interface to the YaST-REST interface automatically. Due the fact that DBUS already provides tools like interspection it should not be a big problem to make this automatically. Currently it is not possible cause not all YaST modules provides the YaST-DBUS interface ( state one month ago :-) ). So we are wrapping via SCR calls now. Please inform me if I am still on the wrong path ;-) Greetings Stefan -- ******************************************************************************* Stefan Schubert SUSE LINUX GmbH - Maxfeldstrasse 5 - D-90409 Nuernberg, Germany e-mail: schubi@suse.de ------------------------------------------------------------------------------- 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
Martin Vidner wrote: [...]
I think that it is a futile attempt to overcome the initial problem of having too many permissions to deal with. How about removing them instead? That means not having the complete "API" of YaST accessible via DBus, but it is not a real API anyway. Instead, we should build the API to fit the permissions.
I agree, IMO me should do it the other way round - create rules first then build the API on top of them. -- 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
Martin Vidner napsal(a):
On Mon, Jun 15, 2009 at 12:10:12PM +0200, Stefan Schubert wrote:
So it makes no sense for the admin who has to set the concerning rights setting each single language right for each user. He only wants to set that the user has read or write access.
We can solve this by using structured name:
org.opensuse.yast.modules.yapi.language.getlanguages org.opensuse.yast.modules.yapi.language.getcurrentlanguage
Should become:
org.opensuse.yast.modules.yapi.language.get-languages org.opensuse.yast.modules.yapi.language.get-currentlanguage
So we are able to generate a tree structure of the rights like get -languages -currentlanguage
Which can be shown in the UI and the admin has to select the root branch "get" or "set" only in order to change the permission for all "child" rights. This will be handled by the permission rest-service of WebYaST.
So you're introducing a regrouping of the action ID, by dashes instead of by dots.
I actually thought that it was a bug, so I fixed it in the webclient: http://git.opensuse.org/?p=projects/yast/web-client.git;a=commitdiff;h=c9af4...
I think that it is a futile attempt to overcome the initial problem of having too many permissions to deal with. How about removing them instead? That means not having the complete "API" of YaST accessible via DBus, but it is not a real API anyway. Instead, we should build the API to fit the permissions.
What about use two tool over permissions? So we provide via dbus atomic permission to change one enclosed atribute and then have in webyast client for changing permission which provide agregate permissions and can change set of atomic permissions like Change http server which ensure that all atomic permission needed for http server is provided (of course provide info what atomic permission it is). I think that for admins is more important what exactly can user change (single values) then high level abstraction permission which can change more then admin want. Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
josef reidinger schrieb:
I think that it is a futile attempt to overcome the initial problem of having too many permissions to deal with. How about removing them instead? That means not having the complete "API" of YaST accessible via DBus, but it is not a real API anyway. Instead, we should build the API to fit the permissions.
What about use two tool over permissions? So we provide via dbus atomic permission to change one enclosed atribute and then have in webyast client for changing permission which provide agregate permissions and can change set of atomic permissions like Change http server which ensure that all atomic permission needed for http server is provided (of course provide info what atomic permission it is). I think that for admins is more important what exactly can user change (single values) then high level abstraction permission which can change more then admin want. Josef
I think we can solve this completely by: - Use granulated permissions if it really needed only. - Using tree structure if a granulation is needed. It is the taks of WebYaST to make this structure useful for the admin. By the way please regard that the REST-webservice acces YaST via the YaST-DBUS interface. This REST-service is running under the user yastws. So permissions has also to be set for this user too. This will be managed in the SPEC file while installing the package. Greetings Stefan -- ******************************************************************************* Stefan Schubert SUSE LINUX GmbH - Maxfeldstrasse 5 - D-90409 Nuernberg, Germany e-mail: schubi@suse.de ------------------------------------------------------------------------------- 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
On Mon, Jun 15, 2009 at 01:19:36PM +0200, josef reidinger wrote:
Martin Vidner napsal(a):
I think that it is a futile attempt to overcome the initial problem of having too many permissions to deal with. How about removing them instead? That means not having the complete "API" of YaST accessible via DBus, but it is not a real API anyway. Instead, we should build the API to fit the permissions.
What about use two tool over permissions? So we provide via dbus atomic permission to change one enclosed atribute and then have in webyast client for changing permission which provide agregate permissions and can change set of atomic permissions like Change http server which ensure that all atomic permission needed for http server is provided (of course provide info what atomic permission it is). I think that for admins is more important what exactly can user change (single values) then high level abstraction permission which can change more then admin want.
So you propose two sets of permissions, atomic and aggregate. That looks the same as what Schubi does with the tree. What is different? Anyway, as I said on Friday, it is a frequent mistake of Linux developers not to care about usability and flood the users with options which the users do not care about. For example, I see if permission_check("org.opensuse.yast.modules.yapi.language.getlanguages") @language.fill_available else logger.info "yast2 language list no permissions" end if permission_check("org.opensuse.yast.modules.yapi.language.getcurrentlanguage") Why on Earth can someone see that the box talks Czech but not that German and Slovak are available too? Or the reverse? Please don't make the admins ridicule us because of that. Make the permissions simple. -- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Martin Vidner napsal(a):
On Mon, Jun 15, 2009 at 01:19:36PM +0200, josef reidinger wrote:
Martin Vidner napsal(a):
I think that it is a futile attempt to overcome the initial problem of having too many permissions to deal with. How about removing them instead? That means not having the complete "API" of YaST accessible via DBus, but it is not a real API anyway. Instead, we should build the API to fit the permissions.
What about use two tool over permissions? So we provide via dbus atomic permission to change one enclosed atribute and then have in webyast client for changing permission which provide agregate permissions and can change set of atomic permissions like Change http server which ensure that all atomic permission needed for http server is provided (of course provide info what atomic permission it is). I think that for admins is more important what exactly can user change (single values) then high level abstraction permission which can change more then admin want.
So you propose two sets of permissions, atomic and aggregate. That looks the same as what Schubi does with the tree. What is different?
Anyway, as I said on Friday, it is a frequent mistake of Linux developers not to care about usability and flood the users with options which the users do not care about.
For example, I see if permission_check("org.opensuse.yast.modules.yapi.language.getlanguages") @language.fill_available else logger.info "yast2 language list no permissions" end if permission_check("org.opensuse.yast.modules.yapi.language.getcurrentlanguage")
Why on Earth can someone see that the box talks Czech but not that German and Slovak are available too? Or the reverse? Please don't make the admins ridicule us because of that. Make the permissions simple.
It is because of efficiency. I need somehow get constant list of supported languages. But current language can change during session and I think that it is vasting of resources to get during each index call whole supported list. So this getlanguages permission is added only due to dbus yast interface. (getLanguages is the biggest performance problem in current language dbus interface as it send quite big data (same problem is in timezone description), for me is unacceptable call on each index call dbus call that take more then second). Josef Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Mon, Jun 15, 2009 at 02:27:12PM +0200, josef reidinger wrote:
Martin Vidner napsal(a):
Why on Earth can someone see that the box talks Czech but not that German and Slovak are available too? Or the reverse? Please don't make the admins ridicule us because of that. Make the permissions simple.
It is because of efficiency. I need somehow get constant list of supported languages. But current language can change during session and I think that it is vasting of resources to get during each index call whole supported list. So this getlanguages permission is added only due to dbus yast interface. (getLanguages is the biggest performance problem in current language dbus interface as it send quite big data (same problem is in timezone description), for me is unacceptable call on each index call dbus call that take more then second).
Language::Get ($["current": true, "all": false, ...]); This concentrates the API to a single point suitable for the permissions, yet it allows you not to waste resources on unused parts. -- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Martin Vidner napsal(a):
On Mon, Jun 15, 2009 at 02:27:12PM +0200, josef reidinger wrote:
Why on Earth can someone see that the box talks Czech but not that German and Slovak are available too? Or the reverse? Please don't make the admins ridicule us because of that. Make the permissions simple. It is because of efficiency. I need somehow get constant list of supported languages. But current language can change during session and I think that it is vasting of resources to get during each index call whole supported list. So this getlanguages permission is added only due to dbus yast interface. (getLanguages is the biggest performance problem in current language dbus interface as it send quite big data (same
Martin Vidner napsal(a): problem is in timezone description), for me is unacceptable call on each index call dbus call that take more then second).
Language::Get ($["current": true, "all": false, ...]);
This concentrates the API to a single point suitable for the permissions, yet it allows you not to waste resources on unused parts.
Yes, this is possible option, that reduces all getters and setters to two functions which returns corresponding answers. Only limitation I see that return type depends on arguments ( or should be map with same problem) so it needs serialize values to same type (string looks sufficient). Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Mon, Jun 15, 2009 at 01:19:36PM +0200, josef reidinger wrote:
What about use two tool over permissions? So we provide via dbus atomic permission to change one enclosed atribute and then have in webyast client for changing permission which provide agregate permissions and can change set of atomic permissions like Change http server which ensure that all atomic permission needed for http server is provided (of course provide info what atomic permission it is). I think that for admins is more important what exactly can user change (single values) then high level abstraction permission which can change more then admin want.
Josef, you must write better, otherwise people will not listen. It is hard to read not because the ideas are hard but because - There are frequent mistakes in English (you know that already). This is actually enough to make my brain hurt, and I sometimes skip what you write just because of that. - The text is not structured. You should - Use paragraphs, make sentences shorter. - Capitalize properly (DBus and HTTP). - Use quotes (...permissions like "Change HTTP server" which ensure...). Please have in mind that you are asking many people on the list to read what you write and think about it. So take the time to read it over yourself and edit it so that the form does not kill the content. -- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
* Josef Reidinger
During developing my webyast modules I find, that using dbus and my YaPI quite increase amount of webyast policykit permissions. Is there any policy how detailed should be that permissions?
I am not aware of any. However, less is usually more. For e.g. language, a simple read and write permission for all language related values looks sufficient. I cannot imagine an administrator willing to fill a spreadsheet-like table of detailed access policies. 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
participants (6)
-
Josef Reidinger -
josef reidinger
-
Klaus Kaempf -
Ladislav Slezak -
Martin Vidner -
Stefan Schubert