[yast-devel] Gloves: Permissions Overview
Hi, I've created an overview drawing of two different solutions for Gloves permissions/roles: low vs high level of roles. See http://bit.ly/Hd20ef Frankly, it seems that neither of them can fully support roles hierarchy as it is presented here: http://bit.ly/GQ8pvZ (or it needs quite a complicated approach how to do that) Check out the links, please, and comment. Bye Lukas -- Lukas Ocilka, Appliances Department SUSE LINUX s.r.o., Praha -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 03/27/2012 06:02 PM, Lukas Ocilka wrote:
Hi,
I've created an overview drawing of two different solutions for Gloves permissions/roles: low vs high level of roles. See http://bit.ly/Hd20ef
Frankly, it seems that neither of them can fully support roles hierarchy as it is presented here: http://bit.ly/GQ8pvZ (or it needs quite a complicated approach how to do that)
We've been discussing this from a different point of view with Michal today: The low-level-perms (on path) make it impossible to configure dynamically created sysconfig files for network (/etc/sysconfig/network/ifcfg-*), whereas the high-level-perms (Network Admin) don't care about specific files (but YLib has to take care about security itself). Bye Lukas -- Lukas Ocilka, Appliances Department SUSE LINUX s.r.o., Praha -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Thu, 29 Mar 2012 11:04:57 +0200
Lukas Ocilka
On 03/27/2012 06:02 PM, Lukas Ocilka wrote:
Hi,
I've created an overview drawing of two different solutions for Gloves permissions/roles: low vs high level of roles. See http://bit.ly/Hd20ef
Frankly, it seems that neither of them can fully support roles hierarchy as it is presented here: http://bit.ly/GQ8pvZ (or it needs quite a complicated approach how to do that)
We've been discussing this from a different point of view with Michal today: The low-level-perms (on path) make it impossible to configure dynamically created sysconfig files for network (/etc/sysconfig/network/ifcfg-*), whereas the high-level-perms (Network Admin) don't care about specific files (but YLib has to take care about security itself).
Bye Lukas
Well, that is not exactly true, as for this specific purpose I plan to create third agent - directory agent, which have permission to create/read/modify/delete any file in directory ( read and modify have almost identical interface as FileAgent ) So you can have permission for directory "/etc/sysconfig/network/" and then you can handle all files in this directory. For me it is still low-level operation and don't need any logic from upper layer. We just need to ensure, that we handle correctly paths ( no path escaping anywhere ). Josef -- Josef Reidinger Software Engineer Appliance Department SUSE LINUX, s. r. o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic jreidinger@suse.com SUSE -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 03/29/2012 11:22 AM, Josef Reidinger wrote:
Well, that is not exactly true, as for this specific purpose I plan to create third agent - directory agent, which have permission to create/read/modify/delete any file in directory ( read and modify have almost identical interface as FileAgent )
In other words, it's exactly true with the current state ;) But you have a solution.
So you can have permission for directory "/etc/sysconfig/network/" and then you can handle all files in this directory. For me it is still low-level operation and don't need any logic from upper layer. We just need to ensure, that we handle correctly paths ( no path escaping anywhere ).
That sounds good. Which also means we are back to zero: We should grab all the pros & cons (as already started during our meeting) for both solutions and then compare them to pick one. Lukas -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Thu, 29 Mar 2012 11:32:11 +0200
Lukas Ocilka
On 03/29/2012 11:22 AM, Josef Reidinger wrote:
Well, that is not exactly true, as for this specific purpose I plan to create third agent - directory agent, which have permission to create/read/modify/delete any file in directory ( read and modify have almost identical interface as FileAgent )
In other words, it's exactly true with the current state ;) But you have a solution.
To be honest, for me your sentence "The low-level-perms (on path) make it impossible to configure dynamically created sysconfig files" looks more like general statement then fact about current status of implementation.
So you can have permission for directory "/etc/sysconfig/network/" and then you can handle all files in this directory. For me it is still low-level operation and don't need any logic from upper layer. We just need to ensure, that we handle correctly paths ( no path escaping anywhere ).
That sounds good. Which also means we are back to zero: We should grab all the pros & cons (as already started during our meeting) for both solutions and then compare them to pick one.
Yes, I agree. I just want to have correct *general* pros/cons ( as implementation can change, API can be modified, but permissions should make huge difference in architecture ( and also in API )). Josef
Lukas
-- Josef Reidinger Software Engineer Appliance Department SUSE LINUX, s. r. o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic jreidinger@suse.com SUSE -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Dne Čt 29. března 2012 11:32:11, Lukas Ocilka napsal(a):
So you can have permission for directory "/etc/sysconfig/network/" and then you can handle all files in this directory. For me it is still low-level operation and don't need any logic from upper layer. We just need to ensure, that we handle correctly paths ( no path escaping anywhere ).
That sounds good. Which also means we are back to zero: We should grab all the pros & cons (as already started during our meeting) for both solutions and then compare them to pick one.
Oh, no, we are not. All mentioned pros & cons still apply, why do you think they don't? Jiri -- Jiri Suchomel SUSE LINUX, s.r.o. e-mail: jsuchome@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Praha 9, Czech Republic http://www.suse.cz -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Well, that is not exactly true, as for this specific purpose I plan to create third agent - directory agent, which have permission to create/read/modify/delete any file in directory ( read and modify have almost identical interface as FileAgent ) So you can have permission for directory "/etc/sysconfig/network/" and then you can handle all files in this directory. For me it is still low-level operation and don't need any logic from upper layer. We just need to ensure, that we handle correctly paths ( no path escaping anywhere ).
There is second part of the problem. There can be many ifcfg-* files, you never know which ones. Moreover, all those files can be processed by one lens (as almost all sysconfig files). So, the discussion was also about "How to create config file agent which is not fixed to particular file" Michal -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Thu, 29 Mar 2012 11:33:30 +0200
"Michal Filka"
Well, that is not exactly true, as for this specific purpose I plan to create third agent - directory agent, which have permission to create/read/modify/delete any file in directory ( read and modify have almost identical interface as FileAgent ) So you can have permission for directory "/etc/sysconfig/network/" and then you can handle all files in this directory. For me it is still low-level operation and don't need any logic from upper layer. We just need to ensure, that we handle correctly paths ( no path escaping anywhere ).
There is second part of the problem. There can be many ifcfg-* files, you never know which ones.
I think that method read should return list of files, so you should know it.
Moreover, all those files can be processed by one lens (as almost all sysconfig files). So, the discussion was also about "How to create config file agent which is not fixed to particular file"
There should be always some restriction. All /etc/sysconfig is just sysconfigs, but permission to this files can be really various. My idea is that inside of add/edit action you have something ( you have ruby, so various nice ways ) that map file to lense. And then you just pass map to augeas with given lense. So in code of directory agent can be something like lense = case file when /ifcfg-.*/ then "sysconfig.lense" when /scrips/ then "bash.lense" else raise "unsuported File" end Pepa
Michal
-- Josef Reidinger Software Engineer Appliance Department SUSE LINUX, s. r. o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic jreidinger@suse.com SUSE -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
There should be always some restriction. All /etc/sysconfig is just sysconfigs, but permission to this files can be really various.
My idea is that inside of add/edit action you have something ( you have ruby, so various nice ways ) that map file to lense. And then you just pass map to augeas with given lense.
So in code of directory agent can be something like
lense = case file when /ifcfg-.*/ then "sysconfig.lense" when /scrips/ then "bash.lense" else raise "unsuported File" end
I haven't so much experience with ruby, so I thought about C++ like approach ;-) class SysconfigAgent < ConfigAgentService::FileService as a generic ancestor of agents accessing sysconfig files (so not binded to particular file) It can use already implemented API. Michal -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Thu, 29 Mar 2012 11:59:47 +0200
"Michal Filka"
There should be always some restriction. All /etc/sysconfig is just sysconfigs, but permission to this files can be really various.
My idea is that inside of add/edit action you have something ( you have ruby, so various nice ways ) that map file to lense. And then you just pass map to augeas with given lense.
So in code of directory agent can be something like
lense = case file when /ifcfg-.*/ then "sysconfig.lense" when /scrips/ then "bash.lense" else raise "unsuported File" end
I haven't so much experience with ruby, so I thought about C++ like approach ;-)
class SysconfigAgent < ConfigAgentService::FileService
as a generic ancestor of agents accessing sysconfig files (so not binded to particular file)
It can use already implemented API.
Michal
Well, to describe current state and plans it is slightly different. We have FileAgent. There should be ( I hope in near future) augeas mixin. so then it should look like Krb5Conf < ConfigAgentService::FileService include AugeasParser # detect that agent use augeas for parsing/writingback augeas_lense = "something.lns" #and define which lense use end #and in common case this should be everything for file agent So it is slightly different and more abstract. Of course you can create class that brings togethere these three lines and name is then enough. Josef -- Josef Reidinger Software Engineer Appliance Department SUSE LINUX, s. r. o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic jreidinger@suse.com SUSE -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Hi, As I can see Sysconfig.lns is used in YaST++/Gloves. I would like to note that this lens is buggy. Correct lens for sysconfig files is Shellvars.lns. Couple of examples processed incorrectly by Sysconfig.lns: # should fail, but pass using Sysconfig.lns FAIL_1='e'e' FAIL_2='e'e'e' FAIL_3=''' FAIL_4=' " FAIL_5='e FAIL_6=e' # should pass, but fails using Sysconfig.lns PASS_1=essid # fails due to this comment all above examples are processed correctly when Shellvars.lns is used Michal Filka -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Dne Čt 29. března 2012 11:27:07, Michal Filka napsal(a):
Hi,
As I can see Sysconfig.lns is used in YaST++/Gloves. I would like to note that this lens is buggy. Correct lens for sysconfig files is Shellvars.lns. ...
Actually, in my config agent code, I started with using Sysconfig.lns for reading and Shellvars.lns for writing: certainly not a good approach in the long term, I used this combination just to have things done in that time. Jiri -- Jiri Suchomel SUSE LINUX, s.r.o. e-mail: jsuchome@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Praha 9, Czech Republic http://www.suse.cz -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
I've found that Shellvars is not perfect too. If you need to process values like VAR1='abc''def' VAR2='abc'"'"'def" it fails. I've prepared a patch and subscribed it to augeas-devel. Michal Filka
Dne Čt 29. března 2012 11:27:07, Michal Filka napsal(a):
Hi,
As I can see Sysconfig.lns is used in YaST++/Gloves. I would like to note that this lens is buggy. Correct lens for sysconfig files is Shellvars.lns. ...
Actually, in my config agent code, I started with using Sysconfig.lns for reading and Shellvars.lns for writing: certainly not a good approach in the long term, I used this combination just to have things done in that time.
Jiri -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Thu, 12 Apr 2012 14:06:56 +0200
"Michal Filka"
I've found that Shellvars is not perfect too. If you need to process values like VAR1='abc''def' VAR2='abc'"'"'def" it fails.
I've prepared a patch and subscribed it to augeas-devel.
Michal Filka
Dne Čt 29. března 2012 11:27:07, Michal Filka napsal(a):
Hi,
As I can see Sysconfig.lns is used in YaST++/Gloves. I would like to note that this lens is buggy. Correct lens for sysconfig files is Shellvars.lns. ...
Actually, in my config agent code, I started with using Sysconfig.lns for reading and Shellvars.lns for writing: certainly not a good approach in the long term, I used this combination just to have things done in that time.
Jiri
Thanks for upstreaming. Then everyone benefit from it and we on other side gets others fixes. Much better situation then with current agents. Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Thanks for upstreaming. Then everyone benefit from it and we on other side gets others fixes. Much better situation then with current agents.
Thanks. Btw. Patch accepted, so one day it will come back to SuSE ;-) Michal -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
participants (4)
-
Jiri Suchomel -
Josef Reidinger -
Lukas Ocilka -
Michal Filka