You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Carl Trieloff <cc...@redhat.com> on 2009/02/17 17:59:07 UTC
Re: Access management with QPid
ffrenchm wrote:
> Hello,
>
> I'm looking now to your access management system thanks ACL. As I understand
> the access management is done in the QPid broker. I would like to know if
> it's possible to move this access management from the broker to another ACL
> access management tool which aims to centralize the IAM configuration. Is
> this possible to move it thanks broker configuration or do we need to
> implement a specific connector ?
>
> Thanks
>
Right now it is file based, I know some guys on the dev list are playing
with pulling the info from remote
or other sources. As ACL is a plugin, it would e easy to add additional
remote interfaces for ACL. Cross
posting to the dev list, as I don't remember who was prototyping/
implementing this.
Carl.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Access management with QPid
Posted by Joshua Kramer <jo...@globalherald.net>.
> Thoughts?
Here are a few thoughts and questions I had after consulting the
SE-PostgreSQL documentation.
In SEPG, the contexts for the tables are created by using an extension to
the table manipulation statements. For example,
ALTER TABLE drink
CONTEXT = 'user_u:object_r:sepgsql_secret_table_t';
I propose that we use a similar mechanism for QPid operations. Any time
an operation is performed - creating a queue, bind to an exchange, etc -
the client app will pass a SELinux context as a named parameter. When
QPid calls the ACL module to see if the client is authorized to do the
action, the SELinux ACL module will note the context passed as the
parameter. If SELinux approves the action, then it will create a record
in an internal table with the new object's ID and its security context,
for future use. Any objects that are created as persistent will have
their context saved to disk.
Some security contexts will need to reside on disk as a bootstrapping
mechanism.
In order to ensure the contexts of remote clients, I propose using
Labelled IPSec as SEPG does.
Thoughts?
Thanks,
-Josh
--
-----
http://www.globalherald.net/jb01
GlobalHerald.NET, the Smarter Social Network! (tm)
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Access management with QPid
Posted by Joshua Kramer <jo...@globalherald.net>.
>> AclModule (which is pluggable). Can that not be implemented as a call to
>> security_compute_av?
>
> yea, I think we might have enough abstraction. We might need to add a map of
> IDs to the object list for SELinux. If that is needed I can volunteer to do
That's what I was thinking, as I took a look at
/qpid/cpp/src/qpid/broker/AclModule.h
...and its friends under qpid/acl. The data in AclModule.h looks like
it's a good representation of the various Actions we'll have to model.
We will need to model the security contexts pertaining to each item. For
example, you can have a file type for an index.htm file, of
httpd_sys_content_t. Contrast this to user_home_t. We might have a
queue, FinancialDataQueue, that should not be able to be read by the
webserver. FinancialDataQueue would have a type of fin_content_t. Since
the contexts are not stored in the Qpid objects themselves, the ACL plugin
will need to map each object to its context. If a user with type httpd_t
attempts to read from FinancialDataQueue, then the authorize call would go
something like this:
1. User Name = 'httpd'
2. Queue Name = 'FinancialDataQueue'
3. Lookup current context of user 'httpd' (that is a SELinux library
call, to find the SELinux user called 'httpd') and find its type to be
httpd_t
4. Lookup current context of queue FinancialDataQueue and find its type to
be fin_content_t
5. Call security_compute_av with the contexts, and pass or fail as needed.
Number 4 is tricky. I am not yet sure if SELinux contexts can be stored
for arbitrary named objects. On the filesystem the are usually stored in
xattrs. Dan?
Thoughts?
--
-----
http://www.globalherald.net/jb01
GlobalHerald.NET, the Smarter Social Network! (tm)
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Access management with QPid
Posted by Carl Trieloff <cc...@redhat.com>.
Gordon Sim wrote:
> Joshua Kramer wrote:
>>
>> Hey, that'd be great! I may also post to the SELinux mailing list.
>> After looking over the SELinux documentation and some other
>> resources, here's what I've found.
>>
>> There are a couple of ways we can go about this. The first way, is
>> to use pseudo-contexts to load ACL's stored in SELinux into QPid
>> ACL's. (Here, 'context' means a SELinux context.) To accomplish
>> access control in this manner, we need to do the following:
>>
>> 1. Create some pseudo-contexts representing QPid objects (things like
>> queues, exchanges, etc.)
>> 2. Go to a file on the filesystem and read in text-based user names.
>> 3. For each name, compute the target contexts that it is allowed to
>> access... and convert those into QPid ACL's.
>>
>> I do not think there is a way to call SELinux and ask it, "give me a
>> list of all the users in the QPid Type, and the things they can
>> access..." But I may be mistaken. There are some third-party
>> SELinux tools for which the source is accessible, so I may peruse
>> those tools.
>>
>> The second way in which we can integrate SELinux into QPid is a bit
>> more complicated. Instead of using the built-in ACL's, we can go
>> into the data structures holding the various QPid objects (queues,
>> exchanges, etc.) and add elements for SELinux security contexts to
>> each object. We would then place calls to security_compute_av before
>> each call that manupulates an object, to determine if that particular
>> operation was permitted.
>
> We already have calls to the authorise() method on the loaded instance
> of AclModule (which is pluggable). Can that not be implemented as a
> call to security_compute_av?
yea, I think we might have enough abstraction. We might need to add a
map of IDs to the object list for SELinux. If that is needed I can
volunteer to do that
Carl.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Access management with QPid
Posted by Rajith Attapattu <ra...@gmail.com>.
On Wed, Feb 18, 2009 at 2:43 PM, Gordon Sim <gs...@redhat.com> wrote:
> Joshua Kramer wrote:
>>
>> Hey, that'd be great! I may also post to the SELinux mailing list. After
>> looking over the SELinux documentation and some other resources, here's what
>> I've found.
>>
>> There are a couple of ways we can go about this. The first way, is to use
>> pseudo-contexts to load ACL's stored in SELinux into QPid ACL's. (Here,
>> 'context' means a SELinux context.) To accomplish access control in this
>> manner, we need to do the following:
>>
>> 1. Create some pseudo-contexts representing QPid objects (things like
>> queues, exchanges, etc.)
>> 2. Go to a file on the filesystem and read in text-based user names.
>> 3. For each name, compute the target contexts that it is allowed to
>> access... and convert those into QPid ACL's.
>>
>> I do not think there is a way to call SELinux and ask it, "give me a list
>> of all the users in the QPid Type, and the things they can access..." But I
>> may be mistaken. There are some third-party SELinux tools for which the
>> source is accessible, so I may peruse those tools.
>>
>> The second way in which we can integrate SELinux into QPid is a bit more
>> complicated. Instead of using the built-in ACL's, we can go into the data
>> structures holding the various QPid objects (queues, exchanges, etc.) and
>> add elements for SELinux security contexts to each object. We would then
>> place calls to security_compute_av before each call that manupulates an
>> object, to determine if that particular operation was permitted.
>
> We already have calls to the authorise() method on the loaded instance of
> AclModule (which is pluggable). Can that not be implemented as a call to
> security_compute_av?
Yep thats exactly what I meant. As it is I believe AclModule has a
resonable abstraction.
Rajith
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Access management with QPid
Posted by Gordon Sim <gs...@redhat.com>.
Joshua Kramer wrote:
>
> Hey, that'd be great! I may also post to the SELinux mailing list.
> After looking over the SELinux documentation and some other resources,
> here's what I've found.
>
> There are a couple of ways we can go about this. The first way, is to
> use pseudo-contexts to load ACL's stored in SELinux into QPid ACL's.
> (Here, 'context' means a SELinux context.) To accomplish access control
> in this manner, we need to do the following:
>
> 1. Create some pseudo-contexts representing QPid objects (things like
> queues, exchanges, etc.)
> 2. Go to a file on the filesystem and read in text-based user names.
> 3. For each name, compute the target contexts that it is allowed to
> access... and convert those into QPid ACL's.
>
> I do not think there is a way to call SELinux and ask it, "give me a
> list of all the users in the QPid Type, and the things they can
> access..." But I may be mistaken. There are some third-party SELinux
> tools for which the source is accessible, so I may peruse those tools.
>
> The second way in which we can integrate SELinux into QPid is a bit more
> complicated. Instead of using the built-in ACL's, we can go into the
> data structures holding the various QPid objects (queues, exchanges,
> etc.) and add elements for SELinux security contexts to each object. We
> would then place calls to security_compute_av before each call that
> manupulates an object, to determine if that particular operation was
> permitted.
We already have calls to the authorise() method on the loaded instance
of AclModule (which is pluggable). Can that not be implemented as a call
to security_compute_av?
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Access management with QPid
Posted by Daniel J Walsh <dw...@redhat.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Carl Trieloff wrote:
>
> Josh,
>
> I have copied Dan, I can comment on the ACL side for Qpid... ... I'll
> leave the SELinux side to Dan.
>
> Carl.
>
>
> Joshua Kramer wrote:
>>
>> Hey, that'd be great! I may also post to the SELinux mailing list.
>> After looking over the SELinux documentation and some other resources,
>> here's what I've found.
>>
>> There are a couple of ways we can go about this. The first way, is to
>> use pseudo-contexts to load ACL's stored in SELinux into QPid ACL's.
>> (Here, 'context' means a SELinux context.) To accomplish access
>> control in this manner, we need to do the following:
>>
>> 1. Create some pseudo-contexts representing QPid objects (things like
>> queues, exchanges, etc.)
>> 2. Go to a file on the filesystem and read in text-based user names.
>> 3. For each name, compute the target contexts that it is allowed to
>> access... and convert those into QPid ACL's.
>>
>> I do not think there is a way to call SELinux and ask it, "give me a
>> list of all the users in the QPid Type, and the things they can
>> access..." But I may be mistaken. There are some third-party SELinux
>> tools for which the source is accessible, so I may peruse those tools.
>>
>> The second way in which we can integrate SELinux into QPid is a bit
>> more complicated. Instead of using the built-in ACL's, we can go into
>> the data structures holding the various QPid objects (queues,
>> exchanges, etc.) and add elements for SELinux security contexts to
>> each object. We would then place calls to security_compute_av before
>> each call that manupulates an object, to determine if that particular
>> operation was permitted.
>>
>> The second way requires more work because it would be tightly woven
>> into many different parts of the broker. The first way is less work
>> because it merely implements an ACL plugin on top of SELinux.
>>
>> So, this is becomes a philosophical discussion. Should we implement
>> QPid ACL's on top of SELinux, or implement SELinux in the broker itself?
>>
>> Cheers,
>> -Josh
>>
>> On Wed, 18 Feb 2009, Carl Trieloff wrote:
>>
>>> Date: Wed, 18 Feb 2009 12:51:01 -0500
>>> From: Carl Trieloff <cc...@redhat.com>
>>> To: Joshua Kramer <jo...@globalherald.net>
>>> Cc: dev@qpid.apache.org, users@qpid.apache.org
>>> Subject: Re: Access management with QPid
>>>
>>> Joshua Kramer wrote:
>>>>
>>>>> remote interfaces for ACL. Cross
>>>>> posting to the dev list, as I don't remember who was prototyping/
>>>>> implementing this.
>>>>
>>>> I am playing with pulling the ACL information from SELinux.
>>>> Currently, I'm determining the best SELinux method to use to get the
>>>> ACL's we need.
>>>>
>>>> Cheers,
>>>> -Josh
>>>>
>>> If you think you know what to do I can forward your ideas to someone
>>> on the SELinux team if you want comment. Some of the guys on SELinux
>>> sit one floor below me ;-)
>>>
>>
>
I think some of your ideas are good, but lets bring in the selinux
developers to see what there take on this is. dbus is a good example of
this use.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkmcXjwACgkQrlYvE4MpobP5JgCfedY5pNniQWTtFCP2b17k7+qL
4eAAoKxLewf341D3K5y1Uxc8/Tyr9tli
=HulE
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Access management with QPid
Posted by Carl Trieloff <cc...@redhat.com>.
Josh,
I have copied Dan, I can comment on the ACL side for Qpid... ... I'll
leave the SELinux side to Dan.
Carl.
Joshua Kramer wrote:
>
> Hey, that'd be great! I may also post to the SELinux mailing list.
> After looking over the SELinux documentation and some other resources,
> here's what I've found.
>
> There are a couple of ways we can go about this. The first way, is to
> use pseudo-contexts to load ACL's stored in SELinux into QPid ACL's.
> (Here, 'context' means a SELinux context.) To accomplish access
> control in this manner, we need to do the following:
>
> 1. Create some pseudo-contexts representing QPid objects (things like
> queues, exchanges, etc.)
> 2. Go to a file on the filesystem and read in text-based user names.
> 3. For each name, compute the target contexts that it is allowed to
> access... and convert those into QPid ACL's.
>
> I do not think there is a way to call SELinux and ask it, "give me a
> list of all the users in the QPid Type, and the things they can
> access..." But I may be mistaken. There are some third-party SELinux
> tools for which the source is accessible, so I may peruse those tools.
>
> The second way in which we can integrate SELinux into QPid is a bit
> more complicated. Instead of using the built-in ACL's, we can go into
> the data structures holding the various QPid objects (queues,
> exchanges, etc.) and add elements for SELinux security contexts to
> each object. We would then place calls to security_compute_av before
> each call that manupulates an object, to determine if that particular
> operation was permitted.
>
> The second way requires more work because it would be tightly woven
> into many different parts of the broker. The first way is less work
> because it merely implements an ACL plugin on top of SELinux.
>
> So, this is becomes a philosophical discussion. Should we implement
> QPid ACL's on top of SELinux, or implement SELinux in the broker itself?
>
> Cheers,
> -Josh
>
> On Wed, 18 Feb 2009, Carl Trieloff wrote:
>
>> Date: Wed, 18 Feb 2009 12:51:01 -0500
>> From: Carl Trieloff <cc...@redhat.com>
>> To: Joshua Kramer <jo...@globalherald.net>
>> Cc: dev@qpid.apache.org, users@qpid.apache.org
>> Subject: Re: Access management with QPid
>>
>> Joshua Kramer wrote:
>>>
>>>> remote interfaces for ACL. Cross
>>>> posting to the dev list, as I don't remember who was prototyping/
>>>> implementing this.
>>>
>>> I am playing with pulling the ACL information from SELinux.
>>> Currently, I'm determining the best SELinux method to use to get the
>>> ACL's we need.
>>>
>>> Cheers,
>>> -Josh
>>>
>> If you think you know what to do I can forward your ideas to someone
>> on the SELinux team if you want comment. Some of the guys on SELinux
>> sit one floor below me ;-)
>>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Access management with QPid
Posted by Rajith Attapattu <ra...@gmail.com>.
Joshua,
I don't think getting SELinux into the broker directly is a good option.
My preference is to have SELinux as an ACL pluggin.
As indicated above, there seems to be interest in using 3rd party ACL
mechanisms to manage access control.
I certainly think it's worth the effort to figure out what needs to be
done in order to make the ACL module sufficiently abstract to achieve
the above.
For starters I think AclModule.h has a reasonable abstraction.
The current tests for ACL is more of integration type and assumes ACL
file based approach. If we go down the above route we would need to
think about how to abstract some of these test cases into a mechanism
independent manner. The obvious choice is to have them in the form of
unit tests.
Regards,
Rajith
On Wed, Feb 18, 2009 at 1:58 PM, Joshua Kramer <jo...@globalherald.net> wrote:
>
> Hey, that'd be great! I may also post to the SELinux mailing list. After
> looking over the SELinux documentation and some other resources, here's what
> I've found.
>
> There are a couple of ways we can go about this. The first way, is to use
> pseudo-contexts to load ACL's stored in SELinux into QPid ACL's. (Here,
> 'context' means a SELinux context.) To accomplish access control in this
> manner, we need to do the following:
>
> 1. Create some pseudo-contexts representing QPid objects (things like
> queues, exchanges, etc.)
> 2. Go to a file on the filesystem and read in text-based user names.
> 3. For each name, compute the target contexts that it is allowed to
> access... and convert those into QPid ACL's.
>
> I do not think there is a way to call SELinux and ask it, "give me a list of
> all the users in the QPid Type, and the things they can access..." But I
> may be mistaken. There are some third-party SELinux tools for which the
> source is accessible, so I may peruse those tools.
>
> The second way in which we can integrate SELinux into QPid is a bit more
> complicated. Instead of using the built-in ACL's, we can go into the data
> structures holding the various QPid objects (queues, exchanges, etc.) and
> add elements for SELinux security contexts to each object. We would then
> place calls to security_compute_av before each call that manupulates an
> object, to determine if that particular operation was permitted.
>
> The second way requires more work because it would be tightly woven into
> many different parts of the broker. The first way is less work because it
> merely implements an ACL plugin on top of SELinux.
>
> So, this is becomes a philosophical discussion. Should we implement QPid
> ACL's on top of SELinux, or implement SELinux in the broker itself?
>
> Cheers,
> -Josh
>
> On Wed, 18 Feb 2009, Carl Trieloff wrote:
>
>> Date: Wed, 18 Feb 2009 12:51:01 -0500
>> From: Carl Trieloff <cc...@redhat.com>
>> To: Joshua Kramer <jo...@globalherald.net>
>> Cc: dev@qpid.apache.org, users@qpid.apache.org
>> Subject: Re: Access management with QPid
>>
>> Joshua Kramer wrote:
>>>
>>>> remote interfaces for ACL. Cross
>>>> posting to the dev list, as I don't remember who was prototyping/
>>>> implementing this.
>>>
>>> I am playing with pulling the ACL information from SELinux. Currently,
>>> I'm determining the best SELinux method to use to get the ACL's we need.
>>>
>>> Cheers,
>>> -Josh
>>>
>> If you think you know what to do I can forward your ideas to someone on
>> the SELinux team if you want comment. Some of the guys on SELinux sit one
>> floor below me ;-)
>>
>
> --
>
> -----
> http://www.globalherald.net/jb01
> GlobalHerald.NET, the Smarter Social Network! (tm)
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Access management with QPid
Posted by Joshua Kramer <jo...@globalherald.net>.
Hey, that'd be great! I may also post to the SELinux mailing list. After
looking over the SELinux documentation and some other resources, here's
what I've found.
There are a couple of ways we can go about this. The first way, is to use
pseudo-contexts to load ACL's stored in SELinux into QPid ACL's. (Here,
'context' means a SELinux context.) To accomplish access control in this
manner, we need to do the following:
1. Create some pseudo-contexts representing QPid objects (things like
queues, exchanges, etc.)
2. Go to a file on the filesystem and read in text-based user names.
3. For each name, compute the target contexts that it is allowed to
access... and convert those into QPid ACL's.
I do not think there is a way to call SELinux and ask it, "give me a list
of all the users in the QPid Type, and the things they can access..." But
I may be mistaken. There are some third-party SELinux tools for which the
source is accessible, so I may peruse those tools.
The second way in which we can integrate SELinux into QPid is a bit more
complicated. Instead of using the built-in ACL's, we can go into the data
structures holding the various QPid objects (queues, exchanges, etc.) and
add elements for SELinux security contexts to each object. We would then
place calls to security_compute_av before each call that manupulates an
object, to determine if that particular operation was permitted.
The second way requires more work because it would be tightly woven into
many different parts of the broker. The first way is less work because it
merely implements an ACL plugin on top of SELinux.
So, this is becomes a philosophical discussion. Should we implement QPid
ACL's on top of SELinux, or implement SELinux in the broker itself?
Cheers,
-Josh
On Wed, 18 Feb 2009, Carl Trieloff wrote:
> Date: Wed, 18 Feb 2009 12:51:01 -0500
> From: Carl Trieloff <cc...@redhat.com>
> To: Joshua Kramer <jo...@globalherald.net>
> Cc: dev@qpid.apache.org, users@qpid.apache.org
> Subject: Re: Access management with QPid
>
> Joshua Kramer wrote:
>>
>>> remote interfaces for ACL. Cross
>>> posting to the dev list, as I don't remember who was prototyping/
>>> implementing this.
>>
>> I am playing with pulling the ACL information from SELinux. Currently, I'm
>> determining the best SELinux method to use to get the ACL's we need.
>>
>> Cheers,
>> -Josh
>>
> If you think you know what to do I can forward your ideas to someone on the
> SELinux team if you want comment. Some of the guys on SELinux sit one floor
> below me ;-)
>
--
-----
http://www.globalherald.net/jb01
GlobalHerald.NET, the Smarter Social Network! (tm)
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Access management with QPid
Posted by Carl Trieloff <cc...@redhat.com>.
Joshua Kramer wrote:
>
>> remote interfaces for ACL. Cross
>> posting to the dev list, as I don't remember who was prototyping/
>> implementing this.
>
> I am playing with pulling the ACL information from SELinux. Currently,
> I'm determining the best SELinux method to use to get the ACL's we need.
>
> Cheers,
> -Josh
>
If you think you know what to do I can forward your ideas to someone on
the SELinux team if you want comment. Some of the guys on SELinux sit
one floor below me ;-)
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Access management with QPid
Posted by Carl Trieloff <cc...@redhat.com>.
Joshua Kramer wrote:
>
>> remote interfaces for ACL. Cross
>> posting to the dev list, as I don't remember who was prototyping/
>> implementing this.
>
> I am playing with pulling the ACL information from SELinux. Currently,
> I'm determining the best SELinux method to use to get the ACL's we need.
>
> Cheers,
> -Josh
>
If you think you know what to do I can forward your ideas to someone on
the SELinux team if you want comment. Some of the guys on SELinux sit
one floor below me ;-)
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Access management with QPid
Posted by Joshua Kramer <jo...@globalherald.net>.
> remote interfaces for ACL. Cross
> posting to the dev list, as I don't remember who was prototyping/
> implementing this.
I am playing with pulling the ACL information from SELinux. Currently,
I'm determining the best SELinux method to use to get the ACL's we need.
Cheers,
-Josh
--
-----
http://www.globalherald.net/jb01
GlobalHerald.NET, the Smarter Social Network! (tm)
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Access management with QPid
Posted by Joshua Kramer <jo...@globalherald.net>.
> remote interfaces for ACL. Cross
> posting to the dev list, as I don't remember who was prototyping/
> implementing this.
I am playing with pulling the ACL information from SELinux. Currently,
I'm determining the best SELinux method to use to get the ACL's we need.
Cheers,
-Josh
--
-----
http://www.globalherald.net/jb01
GlobalHerald.NET, the Smarter Social Network! (tm)
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org