Add generic iterators and a list data type to libsepol
PATCH 1/1 Add generic iterators and a list data type to libsepol
Add a generic iterator data structure and a linked-list implementation based that uses the iterators to libsepol. Includes test cases for the linked-list implementation.
This version is updated to remove improper use of void** based on comments from James Antill.
---
libsepol/include/sepol/errcodes.h | 3 libsepol/include/sepol/iter.h | 237 +++++++++++++++++++++ libsepol/include/sepol/list.h | 234 +++++++++++++++++++++ libsepol/src/iter.c | 186 ++++++++++++++++ libsepol/src/list.c | 419 +++++++++++++++++++++++++++++++++++++ libsepol/tests/libsepol-tests.c | 2 libsepol/tests/test-list.c | 373 +++++++++++++++++++++++++++++++++ libsepol/tests/test-list.h | 12 + 8 files changed, 1466 insertions(+), 0 deletions(-)
libsepol/include/sepol/errcodes.h +3 -0
@@ -22,4 +22,7 @@#define SEPOL_EEXIST -EEXIST#define SEPOL_ENOENT -ENOENT +/* Custom error codes */ +#define SEPOL_ITERSTOP -500 +#endif
libsepol/include/sepol/iter.h new file +237 -0
237 lines not on this page · raw message
libsepol/include/sepol/list.h new file +234 -0
234 lines not on this page · raw message
libsepol/src/iter.c new file +186 -0
186 lines not on this page · raw message
libsepol/src/list.c new file +419 -0
419 lines not on this page · raw message
libsepol/tests/libsepol-tests.c +2 -0
@@ -22,6 +22,7 @@#include "test-linker.h" #include "test-expander.h" #include "test-deps.h" +#include "test-list.h" #include <CUnit/Basic.h> #include <CUnit/Console.h>
@@ -61,6 +62,7 @@ static int do_tests(int interactive, int verbose)DECLARE_SUITE (linker);DECLARE_SUITE (expander);DECLARE_SUITE (deps); +DECLARE_SUITE (list);if (verbose)CU_basic_set_mode (CU_BRM_VERBOSE );
libsepol/tests/test-list.c new file +373 -0
373 lines not on this page · raw message
libsepol/tests/test-list.h new file +12 -0
@@ -0,0 +1,12 @@ +/* Author : Karl MacMillan <[email protected]> */ + +#ifndef __test_list_h__ +#define __test_list_h__ + +#include <CUnit/Basic.h> + +int list_test_init (void ); +int list_test_cleanup (void ); +int list_add_tests (CU_pSuite suite); + +#endif
--
This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 8 lines · Karl MacMillan
Add a generic iterator data structure and a linked-list implementation based that uses the iterators to libsepol. Includes test cases for the linked-list implementation.
This version is updated to remove improper use of void** based on comments from James Antill.
Signed-off-by Karl MacMillan <[email protected]>
Is there no standard utility library out there that could provide these things? Glib? APR?
Signature · 7 lines
Eamon Walsh <[email protected]> National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 5 lines · Eamon Walsh
Quoted 4 lines · Karl MacMillan
Add a generic iterator data structure and a linked-list implementation based that uses the iterators to libsepol. Includes test cases for the linked-list implementation.
Quoted 9 lines
Quoted 5 lines
This version is updated to remove improper use of void** based on comments from James Antill.
Signed-off-by Karl MacMillan <[email protected]>Is there no standard utility library out there that could provide these things? Glib? APR?
In the past, we had decided to not use external libraries because it would pull in a fairly large library (like glib) close to the root of the library dependency tree. If we maintain a complete split between libsepol / libselinux then much of that concern seems to go away. It also means that the extra dependency is only present on managed systems, which doesn't make things worse for embedded.
APR seems aimed at a slightly different problem set (less data structures, more system abstraction).
Glib, on the other hand, would provide everything that we need. In fact, gobject is a perfect fit for the policy object abstraction that I created with many advantages (including support for exporting the objects to other languages like python).
The Pros of using glib:
* All the data structures that we need.
* Better tested foundation.
* Safe string functions.
* Familiar environment for many developers.
* Complete object-oriented layer for the policy rep.
* Easy export to Python and other languages.
* Our code gets much smaller (libsemanage in particular could shrink if we used glib).
The Cons:
* Large dependency.
* Potential security issues in glib (not certain this is a real issue, but glib is fairly big).
* Glib tends to be slightly verbose and boilerplate heavy.
So, if you ask me, I think we should start using glib in libsepol (and eventually libsemanage). I can work up some code to see what the policyrep stuff would look like based on glib if others think this is worth exploring.
Karl
--
This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 15 lines · Karl MacMillan
Glib, on the other hand, would provide everything that we need. In fact, gobject is a perfect fit for the policy object abstraction that I created with many advantages (including support for exporting the objects to other languages like python).
The Pros of using glib:
* All the data structures that we need.
* Better tested foundation.
* Safe string functions.
* Familiar environment for many developers.
* Complete object-oriented layer for the policy rep.
* Easy export to Python and other languages.
* Our code gets much smaller (libsemanage in particular could shrink if we used glib).
Quoted 5 lines
The Cons:
* Large dependency.
* Potential security issues in glib (not certain this is a real issue, but glib is fairly big).
* Glib tends to be slightly verbose and boilerplate heavy.
I'm pretty sure glib is used in a few security relevant places, so I
doubt that's a problem. The "dependency" argument just seems like normal C programmer twitchyness ... glib is at least as portable as what we'd use it in and is included in pretty much every distro.
The only real problem I've ever had with glib is that calling g_new()
calls abort() on failure (and by extension so does everything that allocates in glib).
This also tends to mean that glib code allocates much more freely than
normal C code. But if you can swallow the allocation death pill, it's hard to argue against glib ... IMO.
Signature · 1 line
James Antill <[email protected]>
Quoted 28 lines · James Antill
Quoted 15 lines · Karl MacMillan
Glib, on the other hand, would provide everything that we need. In fact, gobject is a perfect fit for the policy object abstraction that I created with many advantages (including support for exporting the objects to other languages like python).
The Pros of using glib:
* All the data structures that we need.
* Better tested foundation.
* Safe string functions.
* Familiar environment for many developers.
* Complete object-oriented layer for the policy rep.
* Easy export to Python and other languages.
* Our code gets much smaller (libsemanage in particular could shrink if we used glib).Quoted 5 lines
The Cons:
* Large dependency.
* Potential security issues in glib (not certain this is a real issue, but glib is fairly big).
* Glib tends to be slightly verbose and boilerplate heavy.I'm pretty sure glib is used in a few security relevant places, so I
doubt that's a problem. The "dependency" argument just seems like normal C programmer twitchyness ... glib is at least as portable as what we'd use it in and is included in pretty much every distro.
Quoted 6 lines
The only real problem I've ever had with glib is that calling
g_new()
callsabort()on failure (and by extension so does everything that allocates in glib).
This also tends to mean that glib code allocates much more freely than
normal C code. But if you can swallow the allocation death pill, it's hard to argue against glib ... IMO.
I can't swallow the allocation death pill - how does one perform sane cleanup with such behavior? However, looking around, I see you can replace the allocator virtual table with your own functions and there are g_try_* functions that return NULL rather than calling abort. But not clear that helps with its own internal usage of g_new.
David Wheeler's Secure Programming howto notes this behavior as a problem for use of glib in most secure programs.
Signature · 8 lines
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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 36 lines · Stephen Smalley
Quoted 28 lines · James Antill
Quoted 15 lines · Karl MacMillan
Glib, on the other hand, would provide everything that we need. In fact, gobject is a perfect fit for the policy object abstraction that I created with many advantages (including support for exporting the objects to other languages like python).
The Pros of using glib:
* All the data structures that we need.
* Better tested foundation.
* Safe string functions.
* Familiar environment for many developers.
* Complete object-oriented layer for the policy rep.
* Easy export to Python and other languages.
* Our code gets much smaller (libsemanage in particular could shrink if we used glib).Quoted 5 lines
The Cons:
* Large dependency.
* Potential security issues in glib (not certain this is a real issue, but glib is fairly big).
* Glib tends to be slightly verbose and boilerplate heavy.I'm pretty sure glib is used in a few security relevant places, so I
doubt that's a problem. The "dependency" argument just seems like normal C programmer twitchyness ... glib is at least as portable as what we'd use it in and is included in pretty much every distro.Quoted 6 lines
The only real problem I've ever had with glib is that calling
g_new()
callsabort()on failure (and by extension so does everything that allocates in glib).
This also tends to mean that glib code allocates much more freely than
normal C code. But if you can swallow the allocation death pill, it's hard to argue against glib ... IMO.
Quoted 2 lines
I can't swallow the allocation death pill - how does one perform sane cleanup with such behavior?
To be fair, in libsepol we currently just exist on allocation error. Yes, it's better than abort, but we don't really have a need to perform cleanup.
libsemanage is obviously different and I don't think the libsemanage dependency on libsepol is ever going to be removed.
Quoted 5 lines
However, looking around, I see you can
replace the allocator virtual table with your own functions and there are g_try_* functions that return NULL rather than calling abort. But not clear that helps with its own internal usage ofg_new.
This does help internal usage of g_new (verified by code inspection and experimentation). However, glib includes several custom allocators and replacing the allocator vtable did not seem to help there. It might be possible to track down all of the allocators and convince them not to abort, but there may be problems in the future. We could also try catching sigabort but there would be no good way to figure out why the abort was delivered. This is really frustrating and is causing people to not use glib (the X hackers rejected it over this reason).
Any other options (there don't seem to be any obvious ones)? Personally, I vote for the C++ STL but that requires a small change to which some might object. In summary - C sucks and I'm tired of this 1980s programming environment.
Karl
--
This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 10 lines · Karl MacMillan
Quoted 5 lines · Stephen Smalley
However, looking around, I see you can
replace the allocator virtual table with your own functions and there are g_try_* functions that return NULL rather than calling abort. But not clear that helps with its own internal usage ofg_new.This does help internal usage of
g_new(verified by code inspection and experimentation).
Errm, What do you mean here? The vtable calls return NULL on failure
_now_ (they just call libc malloc/realloc/free), they only exist so you can replace them with debugging versions as in g_mem_profile().
g_new() calls g_malloc() which is defined as calling abort(), via.g_error(), on allocation failure. Pretty much everything in glib will break if that changes, for instance g_list_append() calls g_slice_new() as you add something to the linked list, which calls g_malloc() ... and g_list_append() has no error path because it knows it can't fail. Dito. g_hash_table_new_full() on both counts.
Quoted 7 lines
However, glib includes several custom allocators and
replacing the allocator vtable did not seem to help there. It might be possible to track down all of the allocators and convince them not to abort, but there may be problems in the future. We could also try catching sigabort but there would be no good way to figure out why the abort was delivered. This is really frustrating and is causing people to not use glib (the X hackers rejected it over this reason).
Dealing with the abort() is the simple problem, it's how you then get
out from the call to g_queue_push_fail() when it happens four functions calls further down the stack ... without dereferencing NULL a few times.
Quoted 4 lines
Any other options (there don't seem to be any obvious ones)? Personally, I vote for the C++ STL but that requires a small change to which some might object. In summary - C sucks and I'm tired of this 1980s programming environment.
I completely agree, although personally I think C++ sucks more. The
options are pretty sparse, as everyone generally hacks up mediocre versions of exactly what they need (as everyone is loath to have externals deps).
The only other one that comes to mind is NSPR, which is again mostly a
matter of portability with a few other useful things thrown in for good measure. But I'd be loath to recommend it for libsepol (or much else, for that matter).
Of course there are a few million on the internets, of varying quality,
but nothing that's in Fedora that I know of.
Signature · 4 lines
James Antill - <[email protected]> setsockopt(fd, IPPROTO_TCP, TCP_CONGESTION, ...); setsockopt(fd, IPPROTO_TCP, TCP_DEFER_ACCEPT, ...); setsockopt(fd, SOL_SOCKET, SO_ATTACH_FILTER, ...);
Quoted 62 lines · Karl MacMillan
Quoted 36 lines · Stephen Smalley
Quoted 28 lines · James Antill
Quoted 15 lines · Karl MacMillan
Glib, on the other hand, would provide everything that we need. In fact, gobject is a perfect fit for the policy object abstraction that I created with many advantages (including support for exporting the objects to other languages like python).
The Pros of using glib:
* All the data structures that we need.
* Better tested foundation.
* Safe string functions.
* Familiar environment for many developers.
* Complete object-oriented layer for the policy rep.
* Easy export to Python and other languages.
* Our code gets much smaller (libsemanage in particular could shrink if we used glib).Quoted 5 lines
The Cons:
* Large dependency.
* Potential security issues in glib (not certain this is a real issue, but glib is fairly big).
* Glib tends to be slightly verbose and boilerplate heavy.I'm pretty sure glib is used in a few security relevant places, so I
doubt that's a problem. The "dependency" argument just seems like normal C programmer twitchyness ... glib is at least as portable as what we'd use it in and is included in pretty much every distro.Quoted 6 lines
The only real problem I've ever had with glib is that calling
g_new()
callsabort()on failure (and by extension so does everything that allocates in glib).
This also tends to mean that glib code allocates much more freely than
normal C code. But if you can swallow the allocation death pill, it's hard to argue against glib ... IMO.Quoted 2 lines
I can't swallow the allocation death pill - how does one perform sane cleanup with such behavior?
To be fair, in libsepol we currently just exist on allocation error. Yes, it's better than abort, but we don't really have a need to perform cleanup.
libsemanage is obviously different and I don't think the libsemanage dependency on libsepol is ever going to be removed.
Quoted 5 lines
However, looking around, I see you can
replace the allocator virtual table with your own functions and there are g_try_* functions that return NULL rather than calling abort. But not clear that helps with its own internal usage ofg_new.This does help internal usage of
g_new(verified by code inspection and experimentation). However, glib includes several custom allocators and replacing the allocator vtable did not seem to help there. It might be possible to track down all of the allocators and convince them not to abort, but there may be problems in the future. We could also try catching sigabort but there would be no good way to figure out why the abort was delivered. This is really frustrating and is causing people to not use glib (the X hackers rejected it over this reason).
Quoted 4 lines
Any other options (there don't seem to be any obvious ones)? Personally, I vote for the C++ STL but that requires a small change to which some might object. In summary - C sucks and I'm tired of this 1980s programming environment.
I think rolling our own (in C) is the only real option here.
Also, keep in mind that we will continue to have a /sbin/init -> libsepol dependency for the purpose of downgrading policy versions, so external dependencies do matter.
Signature · 8 lines
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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 8 lines · Karl MacMillan
Add a generic iterator data structure and a linked-list implementation based that uses the iterators to libsepol. Includes test cases for the linked-list implementation.
This version is updated to remove improper use of void** based on comments from James Antill.
Signed-off-by Karl MacMillan <[email protected]>
For the entire policyrep patch series so far,
Merge at will.
Signature · 8 lines
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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 8 lines · Stephen Smalley
Quoted 7 lines · Karl MacMillan
Add a generic iterator data structure and a linked-list implementation based that uses the iterators to libsepol. Includes test cases for the linked-list implementation.
This version is updated to remove improper use of void** based on comments from James Antill.
Quoted 8 lines
Quoted 1 line
Signed-off-by Karl MacMillan <[email protected]>For the entire policyrep patch series so far,
Acked-by Stephen Smalley <[email protected]>Merge at will.
Merged as libsepol 2.0.4.
Karl
--
This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 14 lines · Karl MacMillan
Quoted 12 lines · Stephen Smalley
Quoted 8 lines · Karl MacMillan
Add a generic iterator data structure and a linked-list implementation based that uses the iterators to libsepol. Includes test cases for the linked-list implementation.
This version is updated to remove improper use of void** based on comments from James Antill.
Signed-off-by Karl MacMillan <[email protected]>For the entire policyrep patch series so far,
Quoted 8 lines
Quoted 5 lines
Acked-by Stephen Smalley <[email protected]>Merge at will.
Merged as libsepol 2.0.4.
shouldn't this be 2.1.4 or similar since 2.0.4 will be the next revision of trunk?
--
This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 18 lines · Joshua Brindle
Quoted 17 lines · Karl MacMillan
Quoted 15 lines · Stephen Smalley
Quoted 9 lines · Karl MacMillan
Add a generic iterator data structure and a linked-list implementation based that uses the iterators to libsepol. Includes test cases for the linked-list implementation.
This version is updated to remove improper use of void** based on comments from James Antill.
Signed-off-by Karl MacMillan <[email protected]>For the entire policyrep patch series so far,
Acked-by Stephen Smalley <[email protected]>
Quoted 9 lines
Quoted 6 lines
Quoted 3 lines
Merge at will.
Merged as libsepol 2.0.4.
shouldn't this be 2.1.4 or similar since 2.0.4 will be the next revision of trunk?
Yeah - I bumped it to 2.1.0. That sound OK or do we want to leave space for another release of trunk before the merge?
Karl
--
This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 30 lines · Karl MacMillan
Quoted 28 lines · Joshua Brindle
Quoted 26 lines · Karl MacMillan
Quoted 9 lines · Stephen Smalley
Quoted 6 lines · Karl MacMillan
Add a generic iterator data structure and a linked-list implementation based that uses the iterators to libsepol. Includes test cases for the linked-list implementation.
This version is updated to remove improper use of void** based on comments from James Antill.
Quoted 11 lines
Quoted 3 lines
Signed-off-by Karl MacMillan <[email protected]>For the entire policyrep patch series so far,
Acked-by Stephen Smalley <[email protected]>Merge at will.
Merged as libsepol 2.0.4.
Quoted 8 lines
Quoted 3 lines
shouldn't this be 2.1.4 or similar since 2.0.4 will be the next revision of trunk?
Yeah - I bumped it to 2.1.0. That sound OK or do we want to leave space for another release of trunk before the merge?
I think thats fine, hopefully this will be the next release, if not we can adjust when the time comes.
--
This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 18 lines · Joshua Brindle
Quoted 17 lines · Karl MacMillan
Quoted 15 lines · Stephen Smalley
Quoted 9 lines · Karl MacMillan
Add a generic iterator data structure and a linked-list implementation based that uses the iterators to libsepol. Includes test cases for the linked-list implementation.
This version is updated to remove improper use of void** based on comments from James Antill.
Signed-off-by Karl MacMillan <[email protected]>For the entire policyrep patch series so far,
Acked-by Stephen Smalley <[email protected]>
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
Merge at will.
Merged as libsepol 2.0.4.
shouldn't this be 2.1.4 or similar since 2.0.4 will be the next revision of trunk?
It doesn't actually matter, as we can update the version just before merging to trunk.
Signature · 8 lines
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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 27 lines · Stephen Smalley
Quoted 25 lines · Joshua Brindle
Quoted 23 lines · Karl MacMillan
Quoted 20 lines · Stephen Smalley
Quoted 9 lines · Karl MacMillan
Add a generic iterator data structure and a linked-list implementation based that uses the iterators to libsepol. Includes test cases for the linked-list implementation.
This version is updated to remove improper use of void** based on comments from James Antill.
Signed-off-by Karl MacMillan <[email protected]>For the entire policyrep patch series so far,
Acked-by Stephen Smalley <[email protected]>Merge at will.
Quoted 10 lines
Quoted 5 lines
Quoted 3 lines
Merged as libsepol 2.0.4.
shouldn't this be 2.1.4 or similar since 2.0.4 will be the next revision of trunk?
It doesn't actually matter, as we can update the version just before merging to trunk.
but if we ever roll up rpm's for testing this branch it will be undesirable to have overlapping versions.
--
This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 36 lines · Joshua Brindle
Quoted 35 lines · Stephen Smalley
Quoted 32 lines · Joshua Brindle
Quoted 18 lines · Karl MacMillan
Quoted 15 lines · Stephen Smalley
Quoted 10 lines · Karl MacMillan
Add a generic iterator data structure and a linked-list implementation based that uses the iterators to libsepol. Includes test cases for the linked-list implementation.
This version is updated to remove improper use of void** based on comments from James Antill.
Signed-off-by Karl MacMillan <[email protected]>For the entire policyrep patch series so far,
Quoted 9 lines
Quoted 6 lines
Acked-by Stephen Smalley <[email protected]>Merge at will.
Merged as libsepol 2.0.4.
shouldn't this be 2.1.4 or similar since 2.0.4 will be the next revision of trunk?
Quoted 6 lines
Quoted 4 lines
It doesn't actually matter, as we can update the version just before merging to trunk.
but if we ever roll up rpm's for testing this branch it will be undesirable to have overlapping versions.
I'm not sure why one would ever do that (roll up rpms, vs. just make install install-pywrap relabel).
Changing the {VERSION, ChangeLog} on the branch will also prevent clean merges from the trunk.
Signature · 8 lines
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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 1 line · Stephen Smalley
On Thu, 2007-04-26 at 09:43 -0400, Joshua Brindle wrote:
<snip>
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 6 lines
Quoted 3 lines
Merged as libsepol 2.0.4.
shouldn't this be 2.1.4 or similar since 2.0.4 will be the next revision of trunk?
It doesn't actually matter, as we can update the version just before merging to trunk.
Quoted 9 lines
Quoted 2 lines
but if we ever roll up rpm's for testing this branch it will be undesirable to have overlapping versions.
I'm not sure why one would ever do that (roll up rpms, vs. just make install install-pywrap relabel).
Changing the {VERSION, ChangeLog} on the branch will also prevent clean merges from the trunk.
This part was compelling to me (the merging) so I removed the version change completely and the changelog entries.
Karl
--
This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to [email protected] with the words "unsubscribe selinux" without quotes as the message.