On Mon, 2009-08-31 at 08:55 -0500, Manoj Srivastava wrote:
> On Mon, Aug 31 2009, Stephen Smalley wrote:
>
> > On Sun, 2009-08-30 at 10:19 -0500, Manoj Srivastava wrote:
> >> Hi,
> >>
> >> This bug was discovered, and the analysis done, buy Max
> >> Kellermann. I have never been able to replicate the problem, so I can't
> >> help debug this error.
> >>
> >> Strace:
> >> --8<---------------cut here---------------start------------->8---
> >> brk(0x3233000) = 0x3233000
> >> mmap(NULL, 18446744073703178240, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
> >> mmap(NULL, 18446744073703313408, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
> >> mmap(NULL, 134217728, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x7fdfda316000
> >> --8<---------------cut here---------------end--------------->8---
> >>
> >> > 0xffffffffff9ec000 == 18446744073703178240 (the size of the first
> >> > large allocation). It's also equal to -6373376. This just looks like
> >> > an integer underflow, doesn't it?
> >>
> >> --8<---------------cut here---------------start------------->8---
> >> Breakpoint 4, 0x00007f9bc4c05400 in mmap64 () from /lib/libc.so.6
> >> (gdb) p $rsi
> >> $25 = -6373376
> >> (gdb) bt
> >> #0 0x00007f9bc4c05400 in mmap64 () from /lib/libc.so.6
> >> #1 0x00007f9bc4baf6bb in _int_malloc () from /lib/libc.so.6
> >> #2 0x00007f9bc4bb0a78 in malloc () from /lib/libc.so.6
> >> #3 0x00007f9bc5301a8e in sepol_module_package_read (mod=0xb1d170, spf=0xb202e0, verbose=0) at module.c:533
> >> #4 0x00007f9bc4ea7838 in ?? () from /lib/libsemanage.so.1
> >>
> >> (gdb) frame 3
> >> #3 0x00007f9bc5301a8e in sepol_module_package_read (mod=0xb1d170, spf=0xb202e0, verbose=0) at module.c:533
> >> 533 module.c: No such file or directory.
> >> in module.c
> >> (gdb) p len
> >> $26 = 18446744073703176358
> >> (gdb) p i
> >> $27 = 3
> >> (gdb) p nsec
> >> $30 = 4
> >> (gdb) p offsets[i+1]
> >> $28 = 8192
> >> (gdb) p offsets[i]
> >> $29 = 6383450
> >> --8<---------------cut here---------------end--------------->8---
> >>
> >> > line 456:
> >> > len = offsets[i + 1] - offsets[i];
> >>
> >> > Voila, integer underflow. The function module_package_read_offsets()
> >> > reads the offsets from the input file, but does not verify them.
> >> > off[nsec] = policy_file_length(file);
> >> > Here, the check is missing.
> >>
> >> We should probably have:
> >> --8<---------------cut here---------------start------------->8---
> >> off[nsec] = policy_file_length(file);
> >> if (off[nsec] < off[nsec-1]) {
> >> ERR(file->handle, "file size smaller than previous offset (at %u, "
> >> "offset %zu -> %zu", nsec, off[nsec - 1],
> >> off[nsec]);
> >> return -1;
> >> }
> >> --8<---------------cut here---------------end--------------->8---
> >
> > Perhaps I am missing something, but module_package_read_offsets()
> > already checks that the offsets are increasing and aborts if not.
>
> Well, almost. It does check for most of the offsets:
> --8<---------------cut here---------------start------------->8---
>
> 406 for (i = 0; i < nsec; i++) {
> 407 off[i] = le32_to_cpu(buf[i]);
> 408 if (i && off[i] < off[i - 1]) {
> 409 ERR(file->handle, "offsets are not increasing (at %u, "
> 410 "offset %zu -> %zu", i, off[i - 1],
> 411 off[i]);
> 412 return -1;
> 413 }
> 414 }
> --8<---------------cut here---------------end--------------->8---
> So far, so good.
> --8<---------------cut here---------------start------------->8---
> 415
> 416 free(buf);
> 417 off[nsec] = policy_file_length(file);
> 418 *offsets = off;
> 419 return 0;
> --8<---------------cut here---------------end--------------->8---
>
> The problem is line 417, where there is no check; and in the
> case reported, the file length was less than the previous offset, and
> this resulted in a negative number passed to the memory allocator,
> which resulted in a huge allocation request.
>
> Above, I just propose adding a check after line 417.
Check the last offset against the file size, and ensure that we free the
buffer and offset array in the error cases.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
On Mon, 2009-08-24 at 10:57 -0400, Chris PeBenito wrote:
> On Mon, 2009-08-24 at 10:04 -0400, Stephen Smalley wrote:
> > On Mon, 2009-08-24 at 09:54 -0400, Chris PeBenito wrote:
> > > I took the current release of libsemanage and added the patch to add a
> > > bzip blocksize option[1]. The modules in my store were already
> > > compressed with the stock release. I put bzip-blocksize=0 in my
> > > semanage.conf and I do semodule -B and get:
> > >
> > > libsepol.module_package_read_offsets: wrong magic number for module
> > > package: expected 0xf97cff8f, got 0x39685a42 (No such file or
> > > directory).
> > > libsemanage.semanage_load_module: Error while reading from module
> > > file /etc/selinux/strict/modules/tmp/modules/apm.pp. (No such file or
> > > directory).
> > > semodule: Failed!
> > >
> > > If I do semodule -l, it will also get the magic number error. If I
> > > remove the blocksize option, it works again. I was able to reinsert all
> > > of the modules to get it working again with the blocksize 0 option.
> > >
> > > [1] http://userspace.selinuxproject.org/trac/changeset/ee9827000137fed2d3300124115fc1572acafe2f
> >
> > Yes, that's what I would expect. The expectation is that either one
> > would set that option before installing the policy for the first time,
> > or that one completely re-installs the policy after setting that option.
>
> Can we have a little better handling of this case? I don't mind
> reinstalling the policy, but the error messages aren't helpful. In
> addition, with semodule -l being broken, I have to look into the module
> store to see what modules are installed or guess.
Seems like it is just as easy to just support pre-existing compressed
modules, see below.
Explicitly probe for the bzip2 magic string prefix and fall through to
BZ2_bzReadOpen() if the module is bzipped even if bzip-blocksize=0.
Thus bzip-blocksize=0 will prevent any further compression of
subsequently installed/updated modules, but will continue to function
with existing compressed modules.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
On Tue, 2009-08-11 at 08:12 -0400, Daniel J Walsh wrote:
> On 08/10/2009 04:12 PM, Stephen Smalley wrote:
> > On Mon, 2009-08-10 at 16:03 -0400, Stephen Smalley wrote:
> >> On Mon, 2009-08-10 at 11:13 -0400, Daniel J Walsh wrote:
> >>> Currently in F12 if you have file systems that root can not read
> >>>
> >>> # restorecon -R -v /var/lib/libvirt/
> >>> Can't stat directory "/home/dwalsh/.gvfs", Permission denied.
> >>> Can't stat directory "/home/dwalsh/redhat", Permission denied.
> >>>
> >>> After patch
> >>>
> >>> # ./restorecon -R -v /var/lib/libvirt/
> >>
> >> But if you were to run
> >> ./restorecon -R /home/dwalsh
> >> that would try to descend into .gvfs and redhat, right?
> >>
> >> I think you want instead to ignore the lstat error if the error was
> >> permission denied and add the entry to the exclude list so that
> >> restorecon will not try to descend into it. It is ok to exclude a
> >> directory to which you lack permission. Try this:
> >
> > Also, why limit -e to only directories? Why not let the user exclude
> > individual files if they choose to do so? In which case we could drop
> > the mode test altogether, and possibly drop the lstat() call altogether?
> > Or if you truly want to warn the user about non-existent paths, then
> > take the lstat() and warning to the 'e' option processing in main()
> > instead of doing it inside of add_exclude().
> >
> I agree lets remove the directory check and warn on non existing files.
Does this handle it correctly for you?
Remove the directory check for the -e option and only apply the
existence test to user-specified entries. Also ignore permission denied
errors as it is ok to exclude a directory or file to which the caller
lacks permission.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Remove the support for hard linking files in semanage_copy_file, as it
is unsafe and can leave the active store corrupted if something goes
wrong during the transaction. It also can leave the installed policy
files with incorrect file modes or security contexts.
To do this safely, we would need to change all functions that write to
the sandbox files to first unlink the destination file. This was done
in the original patch for the write_file helper but not for other cases.
It would need to be done for all functions that open.*O_CREAT or
fopen.*w on a file in the sandbox.
We also don't want this applied to the installed policy files, as they
need to be created with appropriate file modes and security contexts
that may differ from the sandbox files. At present, the hard link
support will only affect the installed policy files when they are first
created; afterward the link() call will always fail with EEXIST since
they are not unlinked prior to installation (nor would that be safe as
it could leave the system without a policy - rename would make more
sense in that situation). If we were to re-introduce hard link support,
we ought to use different helpers or flags for installing the policy
files than for copying the active store to the temporary sandbox to
avoid affecting both.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Allow the administrator to customize the bzip block size and "small"
flag via semanage.conf. After applying you can add entries like these
to your /etc/selinux/semanage.conf to trade off memory vs disk space
(block size) and to trade off memory vs runtime (small):
bzip-blocksize=4
bzip-small=true
You can also disable bzip compression altogether for your module store
via:
bzip-blocksize=0
The semanage.conf entries are now validated against legal value ranges
at handle creation time.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Change setfiles/restorecon to only call realpath() on the user-supplied
pathnames prior to invoking fts_open(). This ensures that commands such
as restorecon -R /etc/init.d and (cd /etc && restorecon shadow gshadow)
will work as expected while avoiding the overhead of calling realpath()
on each file during a file tree walk.
Since we are now only acting on user-supplied pathnames, drop the
special case handling of symlinks (when a user invokes restorecon
-R /etc/init.d he truly wants it to descend /etc/rc.d/init.d). We can
also defer allocation of the pathname buffer to libc by passing NULL
(freeing on the out path) and we can drop the redundant exclude() check
as it will now get handled on the normal path.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
On Fri, 2009-07-24 at 16:12 -0400, Stephen Smalley wrote:
> On Fri, 2009-07-17 at 10:48 -0400, Thomas Liu wrote:
> > Get setfiles to check paths for seclabel and skip them
> > if it is not supported.
> >
> > Parse /proc/mounts and add paths that do not have seclabel
> > to the exclude list. If another path shows up that does
> > have seclabel, remove it from the exclude list, since setfiles
> > will try and when it fails it will skip it.
> >
> > Also made one of the error messages in add_exclude more
> > descriptive.
> >
> > Signed-off-by: Thomas Liu <tliu@redhat.com>
> > Signed-off-by: Dan Walsh <dwalsh@redhat.com>
> > ---
>
> Thanks, merged in policycoreutils 2.0.68.
Applied this patch on top to free the buffer allocated by getline() and
to free any removed entries from the excludeArray. valgrind
--leak-check=full then shows no leakage.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Get setfiles to check paths for seclabel and skip them
if it is not supported.
Parse /proc/mounts and add paths that do not have seclabel
to the exclude list. If another path shows up that does
have seclabel, remove it from the exclude list, since setfiles
will try and when it fails it will skip it.
Also made one of the error messages in add_exclude more
descriptive.
Signed-off-by: Thomas Liu <tliu@redhat.com>
Signed-off-by: Dan Walsh <dwalsh@redhat.com>
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Revive Steve Grubb's patch for libselinux lazy init and extend it to
address not only the reading of /etc/selinux/config but also probing
for /selinux/class and reading of /selinux/mls. This should reduce the
need for dontaudit rules for programs that link with libselinux and it
should reduce unnecessary overhead.
I did not convert init_selinuxmnt over to lazy init since the functions
that use selinux_mnt are not localized, and it only requires stat'ing
of /selinux in the common case.
I couldn't see a valid reason why we needed fini_obj_class_compat(), as
the existence of /selinux/class will only change across a reboot with
different kernel versions. fini_context_translations() already had a
comment saying that it was unnecessary as well.
Before:
$ strace ls 2> err
$ grep selinux err
open("/lib/libselinux.so.1", O_RDONLY) = 3
open("/etc/selinux/config", O_RDONLY|O_LARGEFILE) = 3
statfs64("/selinux", 84, {f_type=0xf97cff8c, f_bsize=4096, f_blocks=0, f_bfree=0, f_bavail=0, f_files=0, f_ffree=0, f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0
stat64("/selinux/class", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
open("/selinux/mls", O_RDONLY|O_LARGEFILE) = 3
After:
$ strace ls 2> err
$ grep selinux err
open("/lib/libselinux.so.1", O_RDONLY) = 3
statfs64("/selinux", 84, {f_type=0xf97cff8c, f_bsize=4096, f_blocks=0, f_bfree=0, f_bavail=0, f_files=0, f_ffree=0, f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0
Original-patch-by: Steve Grubb <linux_4ever@yahoo.com>
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Patch for semodule command
semodule -B
Will now turn on dontaudit rules
semodule -DB
Will turn off dontaudit rules.
With other patch all other semanage commands will maintain state.
Created by Dan Walsh
Signed-off-by: Christopher Pardy <cpardy@redhat.com>
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Currently any changes made to the policy which require committing a handle cause dontaudit rules to be re-enabled. This is confusing, and frustrating for users who want to edit policy with dontaudit rules turned off. This patch allows semanage to remember the last state of the dontaudit rules and apply them as default whenever a handle is connected. Additionally other functions may check for the file semanage creates to determine if dontaudit rules are turned on. This knowledge can be useful for tools like SETroubleshoot which may want to change their behavior depending on the state of the dontaudit rules. In the event that a the file cannot be created a call to commit will fail.
Signed-off-by: Christopher Pardy <cpardy@redhat.com>
[sds: Removed duplicate from other patch and cleaned up style.]
[sds: Changed uses of semanage_fname to semanage_path.]
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
This patch adds the ability to check on the value of the disable_dontaudit flag in the sepol handle. In the past the only way to know the value of this was to directly read the values from the handle. The get function provides a setter-getter symmetry similar to other functions found in libsepol.
Signed-off-by: Christopher Pardy <cpardy@redhat.com>
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Email: dwalsh@redhat.com
Subject: This patch add seusers support to SELinux
Date: Mon, 18 May 2009 14:20:30 -0400
The idea here is to break the seusers file up into lots of little
seusers file that can be user specific, also adds the service field to
be used by tools like pam_selinux to choose which is the correct context
to log a user in as.
Patch was added to facilitate IPA handing out SELinux content for
selection of roles at login.
Signed-off-by: Joshua Brindle <method@manicmethod.com>
This is version 5 of the setfiles to fts patch.
The code has been cleaned up to adhere to the CodingStyle guidelines.
I have confirmed that the stat struct that fts returns for a symlink when using
the FTS_PHYSICAL flag is in fact the stat struct for the symlink, not the file
it points to (st_size is 8 bytes).
Instead of using fts_path for getfilecon/setfilecon it now uses fts_accpath,
which should be more efficient since fts walks the file hierarchy for us.
FreeBSD setfsmac uses fts in a similar way to how this patch does and one
thing that I took from it was to pass the FTSENT pointer around instead of
the names, because although fts_accpath is more efficient for get/setfilecon,
it is less helpful in verbose output (fts_path will give the entire path).
Here is the output from running restorecon on /
(nftw version)
restorecon -Rv / 2>/dev/null
restorecon reset /dev/pts/ptmx context system_u:object_r:devpts_t:s0->system_u:object_r:ptmx_t:s0
(new version)
./restorecon -Rv / 2>/dev/null
./restorecon reset /dev/pts/ptmx context system_u:object_r:devpts_t:s0->system_u:object_r:ptmx_t:s0
Here are some benchmarks each was run twice from a fresh
boot in single user mode (shown are the second runs).
(nftw version)
restorecon -Rv /usr
real 1m56.392s
user 1m49.559s
sys 0m6.012s
(new version)
./restorecon -Rv /usr
real 1m55.102s
user 1m50.427s
sys 0m4.656s
So not much of a change, though some work has been pushed from kernel space
to user space.
It turns out setting the FTS_XDEV flag tells fts not to descend into
directories with different device numbers, but fts will still give back the
actual directory. I think nftw would completely avoid the directories as well
as their contents.
This patch fixed this issue by saving the device number of the directory
that was passed to setfiles and then skipping all action on any directories
with a different device number when the FTS_XDEV flag is set.
Also removed some code that removed beginning and trailing slashes
from paths, since fts seems to handle it.
Signed-off-by: Thomas Liu <tliu@redhat.com>
[sds: Moved local variable declarations to beginning of process_one.]
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
On Wed, 2009-05-20 at 22:57 +0800, Dennis Wronka wrote:
> Okay, here we go:
>
> I unmounted /selinux and then got this:
> load_policy: Can't load policy: Invalid argument
>
> I attached my kernel-config and the two traces (trace1 for the "Device or
> resource busy"-error, trace2 for the "Invalid argument"-error).
Possible patch for libselinux to a) gracefully handle the situation
where selinuxfs is already mounted, b) report errors when switching to
permissive, and c) proceed with the policy load even if we cannot switch
to permissive mode as requested, as proceeding without a policy when the
kernel only supports enforcing mode is not desirable.
Signed-off-by: Joshua Brindle <method@manicmethod.com>
Al was complaining that he has selinux disabled and has 100,000+ mounts
in /proc/mounts. Every time he runs ls the thing takes 5 seconds
because the libselinux constructor runs the entirety of his /proc/mounts
looking for selinuxfs, which doesn't exist. Speed things up by first
checking for selinuxfs in /proc/filesystems, only if the fs is even
registered should we bother to run all of /proc/mounts.
Signed-off-by: Eric Paris <eparis@redhat.com>
Email: dwalsh@redhat.com
Subject: chcat fixes
Date: Thu, 21 May 2009 08:13:26 -0400
On 05/20/2009 04:05 PM, Chad Sellers wrote:
> On 5/20/09 3:00 PM, "Daniel J Walsh"<dwalsh@redhat.com> wrote:
>
>> Expansion of categores is still broken. Here is a patch to fix.
>>
> This message appears to be missing a patch.
>
> Thanks,
> Chad
>
Signed-off-by: Joshua Brindle <method@manicmethod.com>
Email: dwalsh@redhat.com
Subject: setfiles will only put out a "*" if > 1000 files are fixed.
Date: Wed, 20 May 2009 13:08:14 -0400
setfiles was always putting out a \n, even when not many files were
being fixed. yum transactions were being desturbed by this.
Signed-off-by: Joshua Brindle <method@manicmethod.com>
Email: dwalsh@redhat.com
Subject: Add btrfs to fixfiles.
Date: Wed, 20 May 2009 15:02:33 -0400
Hopefully the last time we will ever need to update. Once patch gets
out with kernel support to tell me which file systems support xattr, we
can remove this hack.
Signed-off-by: Joshua Brindle <method@manicmethod.com>
Email: tmraz@redhat.com
Subject: Problems with freeing thread local storage in libselinux
Date: Wed, 06 May 2009 12:38:35 +0200
On Wed, 2009-05-06 at 01:32 -0500, Manoj Srivastava wrote:
> Hi folks,
>
> There have been numerous reports in Debian and derivatives of
> programs linked with libselinux intermittently getting segfaults.
> There is, for instance, the Debian report 505920[0], and Ubuntu
> reports[1], [3] and [5], and Gnome [2]. I have not been able to
> reproduce the error myself, though I have run the test cases a number
> of times.
>
> The common thread in unclutter, libavg, gst-inspect et al. is a
> segmentation fault in libselinux1, in the 'fini' destructor functions,
> referencing the thread local variables.
>
> The Ubuntu bug log reference my old patch for libselinux from
> 1.X days, where I replaced the thread local storage with regular
> variables and mutexes, and people report success with that. I suspect
> that something is corrupting the thread local storage. From the ubuntu
> report:
> --8<---------------cut here---------------start------------->8---
> Valgrind reports:
> =29183== Invalid read of size 8
> ==29183== at 0xE29B9DD: fini_context_translations (setrans_client.c:211)
> ==29183== by 0xE28F1F1: (within /lib/libselinux.so.1)
> ==29183== by 0xE29D040: (within /lib/libselinux.so.1)
> ==29183== by 0x570010F: exit (exit.c:75)
> 505920==29183== by 0x56E91CA: (below main) (libc-start.c:252)
> ==29183== Address 0x80 is not stack'd, malloc'd or (recently) free'd
> ==29183==
> ==29183== Process terminating with default action of signal 11 (SIGSEGV): dumping core
> ==29183== Access not within mapped region at address 0x80
> ==29183== at 0xE29B9DD: fini_context_translations (setrans_client.c:211)
> ==29183== by 0xE28F1F1: (within /lib/libselinux.so.1)
> ==29183== by 0xE29D040: (within /lib/libselinux.so.1)==29183== by 0x570010F: exit (exit.c:75)
> ==29183== by 0x56E91CA: (below main) (libc-start.c:252)
>
>
> (gdb) bt
> #0 0x00007f3ae812a9dd in fini_context_translations () at setrans_client.c:211
> #1 0x00007f3ae811e1f2 in __do_global_dtors_aux () from /lib/libselinux.so.1
> #2 0x00007ffff9097700 in ?? ()
> #3 0x00007f3ae812c041 in _fini () from /lib/libselinux.so.1
> #4 0x00007ffff9097700 in ?? ()
> #5 0x00007f3af0e88796 in _dl_fini () from /lib64/ld-linux-x86-64.so.2
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
> --8<---------------cut here---------------end--------------->8---
>
> There have been two sets of patches proposed for this; first one
> merely initializes the variables in the init function, and this works
> for a number of people, but at least one person has reported a second
> segfault even with the patch installed[6]
>
> The second patch below converts a thread local cache to a
> process wide cache, with mutex guards, which makes the cache slower,
> and non-thread local caches means that cache misses are more likely.
>
> I'll try and follow up with people who can reproduce the
> problems to see if either one of the patches solve their problems
> without triggering other segmentation faults, but I'd appreciate
> comments if anyone has insight into the issue.
The problem is with freeing storage referenced by TLS variables in
destructors. The destructor is called only in one of the threads and the
variables might not be even properly initialized in that thread. One
possibility is to not free the storage at all but that will leak memory
if the libselinux is loaded/unloaded multiple times in a process.
The only proper way is to use TSD (pthread_key_create,
pthread_setspecific etc.) to store the pointers to the cached contexts.
The attached patch implements this. I did not test it thoroughly though.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
Signed-off-by: Chad Sellers <csellers@tresys.com>
Email: dwalsh@redhat.com
Subject: SELinux context patch
Date: Mon, 18 May 2009 14:16:12 -0400
This patch adds context files for virtual_domain and virtual_image,
these are both being used to locat the default context to be executed by
svirt.
I also included the subs patch which I submitted before. This patch
allows us to substitute prefixes to matchpathcon.
So we can say /export/home == /home
and
/web == /var/www
Author: Chad Sellers
Email: csellers@tresys.com
Flipped free()'s in original patch when strdup'd fail to proper order.
Signed-off-by: Chad Sellers <csellers@tresys.com>
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.
Below is an example using the ruby bindings and produces the similar output
to semodule -l
#!/usr/bin/ruby
require "semanage"
handle = Semanage.semanage_handle_create
Semanage.semanage_select_store(handle, "targeted", Semanage::SEMANAGE_CON_DIRECT)
Semanage.semanage_connect(handle)
module_info = Semanage.semanage_module_list(handle)
modules = Array.new()
module_info[2].times do |n|
temp_module = Semanage.semanage_module_list_nth(module_info[1], n)
mod_string = Semanage.semanage_module_get_name(temp_module).to_s + " " \
+ Semanage.semanage_module_get_version(temp_module).to_s
modules.push(mod_string)
end
puts "List of Installed Modules"
modules.each do |str|
puts str
end
Signed-off-by: David P. Quigley <dpquigl@tycho.nsa.gov>
