On Sun, Jun 25, 2006 at 10:04:33PM +0200, Lars Marowsky-Bree wrote: > On 2006-06-25T17:23:21, Dejan Muhamedagic <[EMAIL PROTECTED]> wrote: > > > Currently, heartbeat authorisation is an all or nothing affair. If > > one can login to one of the cluster computers and run commands as > > root (or hacluster), then he/she can do anything to the cluster. > > Recently, I was in a position to setup a kind of management > > environment for non-root terminal users and basically ended up > > surrendering the whole cluster configuration and management (via > > sudo). I suppose that you all know what I'm talking about. > > > > We need finer resolution access controls. I can see two obvious > > ways to get there: > > > > Identification/Authentication: > > > > 1a) UNIX/OS > > > > 1b) extra authentication protocol and internal user base > > > > Authorisation: > > > > 2a) UNIX security model (users, groups, permissions) > > > > 2b) ACL > > > > The 1a/2a alternatives are simpler to implement and both look > > appropriate for heartbeat. In particular 1b looks like a definite > > overkill. BTW, I suppose that mgmtd already does OS level > > authentication. > > > > The authorisation is more interesting. On the one hand, I suppose > > that it would suffice to use users/groups model as it is. On the > > other, permissions may need to be more elaborate. The simplest, > > yet still useful, way would be to implement only read, write, and > > execute rights. The first two would govern editing the CIB > > objects, whereas the execute bit might be used to allow > > starting/stopping resources and editing constraints. > > Execute is not needed, as the ability to read/write certain objects > already implies the corresponding action. > > > The whole thing could be configured by allowing one or two extra > > attributes per CIB element or they could be implemented "inline", > > along with the "id" attribute. Also, the authorisation attributes > > might be inherited from the parent in the CIB hierarchy. > > I'd suggest to not implement it in the CIB itself, but in the mgmtd at > the front-end level. > > 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. > > It looks like the whole thing should not take to much effort to > > implement. > > > > I guess that one could also make a much more elaborated scheme to > > control access, but I wonder if that would really be necessary. > > > > Your thoughts and comments, please. > > It seems useful, if someone were to implement it, that would be great. > > I'd start with listing the various operations the mgmtd performs (so we > have a clear idea of the privileges to be granted or revoked) and see > how they map to CIB objects. > > 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. 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. 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. 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 ;-) 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/
