On Nov 8, 2007 5:00 AM, Dan Dengate wrote: > Hi Al, > > I should introduce myself first. My name is Dan, I'm based at ..., > working on Unix Installation tools. We are currently working on a > project to rewrite our existing install infrastructure and have been > considering, along with others (existing, and off the shelve), cobbler > for our needs. > > Cobbler is giving us a lot of stuff for free, but for it to succeed it > obviously has to fit all our requirements, or be easily extended for our > environment, as well as sustainable in the future. > > I'm aware that you're currently working on authorization, which is one > our first areas to tackle. It's probably best to discuss this now, > before things start to head in one direction. > > In simple, are requirements are as follows: > > [1] Only certain users should be able to add (remove, edit, etc) > distributions. > > [2] Only certain users should be able to add (remove, edit, etc) > profiles. > > [3] Only the correct "owner" of a system should be able to touch a given > system. > > > What we'd ideally like to do is keep aware from administering any user > information. There are plenty of databases around with all the > information we could ever need. Hopefully that'll be easy to accomplish with plugins and/or scripts to auto-populate cobbler's users. > One ideal solution would be to limit who can add a distribution [1] and > profiles [2] based on maybe, the users Kerberos credentials. The way I've thought about it, we mostly care about systems, since profiles and distributions should be maintained by superusers. Obviously, I'm wrong ;) I'd like to hear more about how you see Cobbler working in your shop as a kind of use-case if you have a need for users to administer distros & profiles. > So there would be a group of people, bob@xxxxxxx, john@xxxxxxxxxx listed > somewhere, like .klogin for example. Bob or John would log on to the > install server and have access to distribution management. > > ...or something along those lines... > > With regard to [3], it gets slightly more confused. For example, we have > a network database which details all the devices on the network, and > maps the device to a responsible and/or main user. This could be pulled into cobbler via triggers or some kind of backend data adapter. For instance, the user code I implemented uses Cobbler's serializer which Michael has conveniently made pluggable. All you'd need to do is write a plugin to pull & map users from your database rather than Cobbler's files. Other users have requested to be able to do this for systems too, specifically against LDAP servers that already have all their system information. > This checking and auth or denying is easy, but how this can map into > Cobbler is where I'm becoming stuck. Originally my idea was to rely on > the Triggers, to check the database and make a decision, returning 1 for > yes user is ok, so they can do stuff, returning zero if they're a > fraudster.. but in talking this through with Michael a little bit, I'm > beginning to move away from this. > > So, there's a lot to take in there. > > I've read the mailing list about the tags. If I understand them > correctly, if a system has a tag 'Dan', only Dan can do stuff with the > object(s) that have that tag? That right. That's pretty close. If a system or its profile has "Dan" and the user has the tag "Dan", then that user has access to the system. The main problem with my tagging approach is that it requires that you be careful about what tags users/systems/profiles get or you could accidentally grant access to things by accident. That's true of any system, but especially easy with something as fast and loose as tag-based authorization. > The idea that sysadmins give root access to users for certain machines, > although is principle is ok, and I'm sure the protection is there, it > just doesn't "feel" right. It feels like we would have to maintain a > list of sudo users.. I'm pretty sure just about any system in cobbler will require sudo to get user-based authorization correct. I'm mainly concentrating on the webui, but noticed that the same code could probably support the CLI via SUDO_USER where the webui would use REMOTE_USER. Maybe it might be worth looking into having a reduced version of the CLI tool that uses XMLRPC like the webui so it doesn't have to run as root. That would make things a bit more interesting ;) > So in conclusion, where is Cobbler going with regard to authorisation > now? Michael's in requirements gathering phase, AFAIK. I'm just throwing together prototypes to see what's easy. Once we figure out an approach that works for most people, it'll probably fall together pretty quickly. > Michael says he's looking at the IPA stuff, which doesn't seem all that > bad, but how it fits together, I've no idea. It looks like a nice suite, but I don't think people would appreciate cobbler being hooked too tightly to any single system, since near 100% of users already have some kind of system in place. I also don't think they're providing much in the way of API's yet (could be wrong), which is really what we'd want. The webui is already pretty trivial to put behind kerberos for authentication using any number of Apache modules, as of 0.6.3. Authorization will be trickier, since that's often done using some kind of LDAP or SQL scheme. Cobbler is trying to stay agnostic towards databases, which is a nice idea, but leaves us on our own for implementing an auth system - we can't just borrow somebody else's wholesale. I've considered extending the webui's usage of PATH_INFO so that it'll be easier to have apache modules implement authorization behind Cobbler's back, similar to how you can have sudo parse command line options. For instance, you could do: dan localhost=/usr/bin/cobbler system edit --name=dan_workstation bob localhost=/usr/bin/cobbler system edit --name=bob_workstation This is hacky though and a PITA to administer, though it wouldn't be too bad if you autogenerated it from a database. Instead I'd like to see: dan localhost=/usr/bin/cobbler And have cobbler check if "dan" has edit access on "dan_workstation". That raises a couple more questions: 1. Do we only care about write access? 2. Does anybody have a need to grant read access to only parts of cobbler? 3. Please tell us if you would have use for user-based authorization in the cobbler CLI. If we only care about the webui, completely different approaches can be taken. > Many Thanks > Dan Dengate _______________________________________________ et-mgmt-tools mailing list et-mgmt-tools@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/et-mgmt-tools
