On Mon, Jul 03, 2006 at 07:53:02PM +0200, Lars Marowsky-Bree wrote:
> On 2006-06-27T12:37:11, Dejan Muhamedagic <[EMAIL PROTECTED]> wrote:
>
> > > 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.
>
> Hm, ok.
>
> I'm not sure that Unix semantics are that good though. Unix doesn't deal
> with visibility well, nor inheritance. A (POSIX) ACL based model might
> be better.
Can you please clarify? What do you mean by visibility and
inheritance? It seems to me that the FS style permissions could be
just the right tool for our purpose.
> > > 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.
>
> No, actually, I was not, but the two are naturally tied together of
> course. I wanted to use mgmtd to authenticate, that's true, but then
> to use that authenticated identity to authorize the requests.
>
> > 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.
>
> The point is well taken.
>
> So, let's assume we store it within the CIB, say, by referencing a
> security object in the attributes to the XML element. (Leaving open the
> question how this is then applied to the dynamically generated status
> section, unless of course we want to expose full cluster status to
> everyone, which is a possible answer.)
Yes, I think having the status section readable for all should be
OK. Otherwise, it might get complex.
> I don't actually mind storing that within the CIB, but I do mind the CIB
> being the one to enforce this, because it is fairly complex, _and_ it
> would require the CIB to deal with authenticating its peers.
>
> (Well, maybe that isn't too bad a move. We could use IPC credentials
> locally, and I assume the mgmtd on the server would run with user
> context, so that would apply to its CIB connection too. Tempting.)
What I had in mind is that authentication (in whatever form:
IPC/PAM/...) happens long before cib tries to read/write
something and that it is (the user id) readily available at that
time.
> > 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.
>
> Well, ultimately, by giving him write access to the instance_ &
> meta_attributes set governing it, I assume. Actually, not the whole
> meta_attributes section, as this could yield access to (for example)
> the priority, which might have an impact on other resources. So, just
> target_role & is_managed.
Neat point.
> What part of the configuration is the user supposed to be able to _see_,
> though? Obviously, he needs to see the object he wants to modify, and
> the path to it.
They will see only what they are allowed to see. We should just
follow whatever has been set in the CIB. Actually, I think it
could be sometimes useful that they can modify, but cannot read.
> What status is he supposed to see?
This is not easy for me to answer. But I think we can just open
the status for reading for everybody.
> Anyway, yes, I think I see where this is going, and it does make sense.
> Do you have a concrete proposal as how the syntax & semantics could look
> like? Is there some XML standard already dealing with embedding
> authorization into XML data?
Wouldn't know, but I'll take a look. Unfortunately, my XML is not fluent.
The most general solution would be to have it along with the
object's ID ("inline"). In that case we won't be limited to a
particular object level and we could, for example, prohibit
reading only some sensitive attributes. Note that they will mainly
be empty because the objects would inherit the permissions from
the parent. That might be an overkill though.
Another issue could be the performance or how big a penalty would
be to enforce security policy. I haven't got a clue how often the
cib elements are read or written.
Cheers,
Dejan
>
>
>
> Sincerely,
> Lars Marowsky-Br?e
>
> --
> High Availability & Clustering
> SUSE Labs, Research and Development
> SUSE LINUX Products GmbH - A Novell Business -- Charles Darwin
> "Ignorance more frequently begets confidence than does knowledge"
>
> _______________________________________________________
> 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/
_______________________________________________________
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/
