Simon Horman wrote:
> [ Reposting as I sent it to linux-ha-devel instead of
> linux-ha-devel the first time around ]
>
> This seems to be a bit of an easy trap to fall into.
> Are there any fixes floating around? I was thinking
> that perhaps a cluster id of some sort would be a good
> idea. But I'm not sure.
With only one role possible ("cluster member"), the distinction between
authentication and authorization is very small.
With only one role possible, it isn't completely clear what the value of
having someone be authenticated but not authorized. If they aren't
authorized as "cluster member", then they have NO role they can play in
the cluster.
If you're a cluster member, then you're a full peer. If you're not a
cluster member, then you're nobody.
But, what value there is, is implemented by the "node" directive for
those who don't want to use autojoin. If you're authenticated but not
authorized by this mechanism, it's almost certainly an error, so we
print error messages for such communication.
With autojoin enabled, if you're authenticated as cluster member, then
you area also authorized to take the role of "cluster member".
The two only truly need to be separate when there is more than one role
possible.
We don't have more than one possible role for this communication
mechanism - and we won't have from this authentication source.
If you make the mistake described in the email, and you don't change the
host name either, then you're completely screwed - and adding some kind
of authorization mechanism won't help you. Because cloning it onto a
new machine is indistinguishable from restoring it onto replacement
hardware for something broken.
So, you're probably going to change the system name. While you're at
it, turn off heartbeat or fix the configuration.
The moral of the story is, if you're going to be a system administrator,
you need to know how to do some things properly, and how to recover from
them when you screw up. Security mechanisms are NOT designed to keep
admins from screwing up. They're designed to keep bad guys out. If
admins with root privileges are going to screw up, security mechanisms
are not going to make everything happy.
I'd love to avoid this problem in general - if it were easy.
But if the best we can do is raise the overhead of managing the systems,
rewrite the software, and make everything else harder to avoid one case
where the admin screws up, but leave many other cases uncovered, then
I'm not interested. And, I suspect that's the best we can do.
Anyone who has a concrete proposal for how this can be fixed for all
cases correctly without a complete rewrite of the communications layer
is encouraged to suggest it.
Horms might have made the beginnings of such a proposal, but I didn't
understand what he said.
--
Alan Robertson <[EMAIL PROTECTED]>
"Openness is the foundation and preservative of friendship... Let me
claim from you at all times your undisguised opinions." - William
Wilberforce
_______________________________________________________
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/
