Re: [PATCH] libsemanage: Add Ruby Bindings

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2009-05-07 at 14:19 -0400, Daniel J Walsh wrote:
> On 05/07/2009 01:11 PM, David P. Quigley wrote:
> > On Thu, 2009-05-07 at 13:10 -0400, Joshua Brindle wrote:
> >> David P. Quigley wrote:
> >>> From: David P. Quigley<dpquigl@xxxxxxxxxxxxxxxxxxxxxxxxx>
> >>>
> >>> This patch adds a SWIG specification file for ruby bindings for libsemanage.
> >>> The spec file is almost identical to the python SWIG file with the exception
> >>> that all list generating typemaps have been removed and the python related
> >>> functions have been replaced with the corresponding ruby ones. Finally the
> >>> Makefile is modified to be able to build the new bindings. Something to note is
> >>> that on 64-bit systems ruby.h might be found somewhere under /usr/lib64 instead
> >>> of /usr/lib so LIBDIR=/usr/lib64 will be needed to build the ruby bindings from
> >>> source.
> >> What is going to be using these bindings?
> >
> > I currently have several Facter addons for Puppet that make use of them.
> > We are looking into what can be done to expand Puppet's ability to
> > effectively manage systems with SELinux.
> >
> > Dave
> >
> >
> > --
> > This message was distributed to subscribers of the selinux mailing list.
> > If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
> > the words "unsubscribe selinux" without quotes as the message.
> My concern with doing this patch is that we end up with puppetd being 
> able to manage selinux policy directly rather then executing semanage 
> command.  But for now puppetd needs to run as an unconfined domain.

I don't think we gain much by such separation, as puppetd will run in a
single domain (so even with policy access control in libsemanage, we
would still end up allowing puppetd_t to make any desired policy
changes) and it would control all the inputs to semanage.

Forcing it to use a helper utility rather than being able to directly
use the interface will just make error handling and reporting more
awkward and will make it slower (as motivated the bindings for
libselinux, right?).  There is no real trust boundary there.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.

[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux