On Mon, Jun 26, 2006 at 05:09:42PM +0200, Lars Marowsky-Bree wrote: > On 2006-06-26T15:32:59, Dejan Muhamedagic <[EMAIL PROTECTED]> wrote: > > > > The CIB and the raw commands for managing it (cibadmin etc) equal root > > > level (which they require to run anyway), which the GUI/CIM provider can > > > then restrict for particular users. > > > > Actually, my idea is to have cibadmin authenticate as well. At > > least now (that may change in future) one does need cibadmin to > > manage the cluster. For example, cibadmin is the only way to > > create/remove/modify constraints. > > Well, that's not true. The GUI also does it. > > If we had CLI tools which went through the mgmtd too, these would > obviously also export this. > > > > As a further step, it bugs me personally to no end that we have the > > > crm_resource etc commands and corresponding functionality within the > > > mgmtd and CIM provider; it'd be much more useful if they went through > > > the same gateways before ending up in the CIB, and thus were subject to > > > the same restrictions. > > > > Agreed. > > > > > That would seem to be more sane to me than implementing the ACLs at the > > > CIB level itself (which, being such a critical part, I'd prefer to keep > > > as simple as possible, which is already bad enough). > > > > Heartbeat v2 supports many different configurations and it is hard > > to foresee all possible uses. Having access control in the CIB > > itself, where every object would have a possibility to keep its > > own access rights allows flexibility which would be on a par with > > Heartbeat itself. > > > > The CIB is definitely the critical part, but at the same time it > > is the core of the cluster. I suspect that all new features will > > have its impact on the CIB. So, I don't think one can prevent CIB > > from becoming more complex. > > Actually, no. Not many features have a direct impact on the CIB. Very > few, really. On the data _stored_ within the CIB, sure, but not on the > CIB code itself. > > If each object carried its own permissions, obviously updating the > permissions would be a different operation from merely being allowed to > read/write the object itself, no?
Right. What I had in mind is a UNIX FS paradigm. So, the parent's write access should control changes of security attributes of children objects. > I think this is really best handled in the mgmtd, which is the code > which deals with authenticating users (be it for the GUI or the CIM > provider or potentially a future generation of CLI tools) already. > > > That, however, does not mean that one should haphazardly change > > the CIB. What I suggested is adding few attributes. I don't see > > that as significant change. Any resource agent can do that. > > Well, you want the CIB to _interpret_ these attributes, and even enforce > user context for its connections. That's a bit beyond. > > > Furthermore, it should be possible to have good separation of > > security from the current (and future) functionality: both when it > > comes to keeping the cluster safe and keeping it running as > > intended. > > Right. Thus, data is stored in the CIB, and ACLs are enforced by the > tools accessing it. Sounds wonderful ;-) > > cibadmin is the raw tool meant for the knowledgeable admin. It gives > access to everything in an unrestricted manner, sort of like a root > shell ;-) crmadmin is, in a way, in the similar category. > > > Finally, I must say that whatever view of Heartbeat I have is > > basically the view of a user. So, I might be very wrong here and > > there and perhaps overall ;-) > > No, I agree with the _idea_ of having ACLs on these operations. > > But, the CIB is the wrong place. The CIB is an abstract data store which > doesn't interpret its own data. That's good. I'd like to keep it that > way. > > The mgmtd already has user authentication, network access methods etc. > Why should the commandline tools only be able to operate on the local > node? If we had CLI tools going through mgmtd, we could use them to > manage a remote cluster too. > > If we have ACLs in mgmtd, all problems would be solved... It seems to me that you were mostly talking about authentication, whereas my main point is authorisation. At any rate, it is not clear to me how to deal with it if not storing permissions close to the data itself. If we take a filesystem as an example, the permissions for every object (file) is stored in its inode. Since we don't have any kind of metadata here, the only place is the CIB itself. I'll give a real life example. Let's say that we have a cluster running some web applications. The web applications are running as user appadmin and deployed (updated) by the same user. How do I configure the cluster so that this user can stop/start/manage/unmanage his applications? Not less and certainly not more. Cheers, Dejan _______________________________________________________ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
