[rsbac] 1.2.8 uploaded to pre

Amon Ott ao at rsbac.org
Wed Aug 23 09:28:23 CEST 2006


On Mittwoch 23 August 2006 01:27, Bencsath Boldizsar wrote:
> To be honest, I'm somewhat frustraded by the new rsbac versions.
> Whereas it is very good news to get new features, but actually 
sometimes 
> it is very complicated to follow the versions.
> Eg. the latest kernel security hole is just on the bugtraq and now 
I'd 
> have to update the kernel of the computers. Yes, but ipsec is 
unstable 
> (openswan) and 2.6 kernels sometimes also fail.
> 
> After that when I really find a version that is usable, the rsbac is 
so 
> much changed, that I must go to every remote location to update 
rsbac, 
> because a simple update surely causes hangs (rc_not_granted (e.g 
> get_status) or acl problems).

I am sorry to hear about this frustration, and I understand it well.
After 1.2.5, the 1.2 series has been meant to only contain bugfixes 
and fix security holes. It is intended to work out of the box with 
existing configurations. Still, some bugfixes make RSBAC work the way 
it was designed instead of somehow different. One example is the IPC 
RC type, which was not taken from the default_ipc_create_type of the 
current role.

All new features go into 1.3, which will form its own stable 
bugfix-only series after the 1.3.0 release. This means that new 
features after 1.3.0 will go into 1.4-pre. We expect 1.3.0 to come 
within the next two months after at least one more pre, and 1.3 will 
certainly require some reconfiguration. We already upgraded our main 
product to RSBAC 1.3-pre for its next release, and 1.3 looks very 
good so far.

1.2 will continue to be supported, bugfixed and ported to new kernel 
versions as long as we can manage, probably at least until 1.4.0 gets 
released.
 
> So at every rsbac update I have to make plans and tests and after 
that go 
> to the remote location, then the library or the c compiler fails etc 
etc.

Unfortunately, compilers and libraries tend to change a lot between 
versions. We do our best to keep up to all versions so that RSBAC 
compiles and works on all systems. GCC 2.95 - 4.1, all major archs, 
2.4 and 2.6 kernels, etc.
 
> Of course rsbac update-upgrade is also a must as all the old 
versions 
> won't be available for the freshest kernels.

For 2.4 kernels, it is rather easy to forward or backward port RSBAC 
versions. You can always ask for a specific combination, and we will 
try to provide it.
 
> So I do not really know how others feel, but I'd be happy with less 
> frequent version changes, more bugfixes, and more information on 
upgrading 
> than having new feauters.

We would be happy about less frequent releases, too. The point is that 
the 2.6 kernel changes so much between two releases that we regularly 
have to change internals and then cannot easily backport to older 2.6 
any more. Every 2.6 version we support is a completely different 
system, which needs regular maintenance.

To make it clear: I hate the way 2.6 develops, but most people expect 
RSBAC to run on the latest kernels. As an example, we (m-privacy) use 
only 2.4 kernels on server systems, because we do not trust 2.6 to 
work reliably and we cannot make our customers upgrade kernels and 
reboot for every daily "stable" 2.6 snapshot 2.6.x.y. And upgrading 
RSBAC since 1.2.5 has been no issue on all our 2.4 systems.

After looking through the changelog again, RSBAC upgrades from 1.2.5 
onwards to 1.2.8 should have worked for you without config changes, 
unless you use one of the bugfixed special features like the 
def_ipc_create_type.

Generally speaking: Like most free software projects, we also have 
quite limited ressources, and we must rely on other people's feedback 
for new versions. We release pre versions early and often and have 
public svn access with full kernel trees, asking for feedback with 
every pre. If we do not get any and do not find any bugs by our own 
testing, all we can do is release the new version.

Amon.
-- 
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22


More information about the rsbac mailing list