Thanks Nish.  I'll open an issue on github this afternoon.

On a somewhat related note - I was going to poke around with my LDAP issue from 
the other day, and I'm trying to figure out how to get the dev environment 
setup for cobbler_web.  I cloned down the cobbler repository from github, and 
did a "make webtest".  Cobbler and Apache start up fine, and I can run cobbler 
commands from the CLI, but I get a 500 error when I hit 
http://127.0.0.1/cobbler_web, and it looks like I'm missing some files under 
/usr/share/cobbler/web.  My directory looks like this:

> ls /usr/share/cobbler/web
> cobbler.wsgi templates

I'm missing all the Django-related files (views.py, urls.py, settings.py, etc). 
 Am I doing something wrong here?  Do I need to do something in addition to 
"make webtest" to get cobbler_web running?  In looking at the repository, it 
looks like the files I need are split across different directories.

-----Original Message-----
From: Nishanth Aravamudan [mailto:n...@linux.vnet.ibm.com] 
Sent: Thursday, August 13, 2015 8:28 AM
To: Kyle Flavin <kyle.fla...@citrix.com>
Cc: cobbler-devel@lists.fedorahosted.org
Subject: Re: [cobbler-devel] authz_ownership not checking permissions correctly 
on system creation

On 12.08.2015 [16:55:31 +0000], Kyle Flavin wrote:
> I've been experimenting with the ownership features in Cobbler, using the 
> authz_ownership module.
> My users.conf looks like this:
> [admins]
> admin = ""
> cobbler = ""
> 
> [mygroup]
> myuser = ""
> I'm seeing a problem where "myuser" can edit systems in the WebUI, 
> owned by "mygroup" that already exist, but "myuser" can't create new 
> systems. I get an authorization error, that seems to be tied back to 
> item_system.py, which loads the obj.owners as the string "<<inherit>>"
> for a new system object (even if I try to create the object with group 
> "mygroup").  The function __is_user_allowed() seems to expect a list 
> here, and ends up iterating over this string, and incorrectly checks 
> for user/group matches against each character in the string - ie: "<".
> Not sure if this is a known issue? I'm running 2.6.9 on my server 
> (latest from the EPEL repos), but it looks like it's unchanged in the 
> latest version up on github as well.  Is this a bug?

I think so. I've noticed that several times in the code, "<<inherit>>"
needs to be special-cased or violates assumptions (like obj.owners is a list 
not a string). The change below might fix it. Care to open an issue on github? 
And I can send a fix via github (nacc is my user on there, if you can subscribe 
when you file it).

> The code snippet is here.  When creating a system, obj.owners is a 
> string containing "<<inherit>>":
> def __is_user_allowed(obj, groups, user, resource, arg1, arg2):
>     if user == "<DIRECT>":
>         # system user, logged in via web.ss
>         return True
>     for group in groups:
>         if group in [ "admins", "admin" ]:
>             return True
>     if obj.owners == []:
>         return True

      if obj.owners == "<<inherit>>":
          return __is_user_allowed(obj.get_conceptual_parent(), groups, user, 
resource, arg1, arg2)

>     for allowed in obj.owners:
>         if user == allowed:
>            # user match
>            return True
>         # else look for a group match
>         for group in groups:
>             if group == allowed:
>                 return True
>     return 0

Should this ^^ be False?

> Thanks,
> Kyle
> 
> 

> _______________________________________________
> cobbler-devel mailing list
> cobbler-devel@lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/cobbler-devel

_______________________________________________
cobbler-devel mailing list
cobbler-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/cobbler-devel

Reply via email to