[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