[gentoo-amd64] catch 22 with realtime-lsm and commoncap (capability dependency) modules

[gentoo-amd64] catch 22 with realtime-lsm and commoncap (capability dependency) modules

[Kyle Lutze]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm trying to load both realtime-lsm and capability, but I can only load
one. the error I get is:

FATAL: Error inserting realtime
(/lib/modules/2.6.16-gentoo-r1-apple1/extra/realtime.ko): Invalid module
format

now if I load realtime first, and then try to load capability I get

WARNING: Error inserting commoncap
(/lib/modules/2.6.16-gentoo-r1-apple1/kernel/security/commoncap.ko):
Invalid module format
FATAL: Error inserting capability
(/lib/modules/2.6.16-gentoo-r1-apple1/kernel/security/capability.ko):
Invalid argument

I know commoncap is the culprit, by why?

dmesg output:
realtime: exports duplicate symbol cap_vm_enough_memory (owned by commoncap)

Realtime LSM initialized (group 18, mlock=1)
commoncap: exports duplicate symbol cap_vm_enough_memory (owned by realtime)
Failure registering capabilities with primary security module.


I would try and fix it myself, but google showed nothing when just
searching for "exports duplicate symbol cap_vm_enough_memory."
any ideas?

/etc/modules.d/realtime file:
options realtime mlock=1 gid=18



thanks,
Kyle
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2-ecc0.1.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFES8KCVFIipMnXxfYRAsC+AKCGB3bPqytW9T1RCVQW+fPBg3Hg9QCghfRx
eusfIctjpWk/vyXGzVpBJP4=
=JpA0
-----END PGP SIGNATURE-----
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] catch 22 with realtime-lsm and commoncap (capability dependency) modules

[Kyle Lutze]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kyle Lutze wrote:
> I'm trying to load both realtime-lsm and capability, but I can only load
> one. the error I get is:
> 
> FATAL: Error inserting realtime
> (/lib/modules/2.6.16-gentoo-r1-apple1/extra/realtime.ko): Invalid module
> format
> 
> now if I load realtime first, and then try to load capability I get
> 
> WARNING: Error inserting commoncap
> (/lib/modules/2.6.16-gentoo-r1-apple1/kernel/security/commoncap.ko):
> Invalid module format
> FATAL: Error inserting capability
> (/lib/modules/2.6.16-gentoo-r1-apple1/kernel/security/capability.ko):
> Invalid argument
> 
> I know commoncap is the culprit, by why?
> 
> dmesg output:
> realtime: exports duplicate symbol cap_vm_enough_memory (owned by commoncap)
> 
> Realtime LSM initialized (group 18, mlock=1)
> commoncap: exports duplicate symbol cap_vm_enough_memory (owned by realtime)
> Failure registering capabilities with primary security module.
> 
> 
> I would try and fix it myself, but google showed nothing when just
> searching for "exports duplicate symbol cap_vm_enough_memory."
> any ideas?
> 
> /etc/modules.d/realtime file:
> options realtime mlock=1 gid=18
> 
> 
> 
> thanks,
> Kyle

another part to my problem,
when trying to run jackd with realtime loaded, even with any=1 instead
of gid=18, I get

11:13:00.764 /usr/bin/jackd -R -dalsa -dhw:1 -r48000 -p128 -n2
11:13:00.771 JACK was started with PID=5010 (0x1392).
jackd 0.100.7
Copyright 2001-2005 Paul Davis and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK compiled with System V SHM support.
loading driver ..
apparent rate = 48000
creating alsa driver ... hw:1|hw:1|128|2|48000|0|0|nomon|swmeter|-|32bit
control device hw:1
configuring for 48000Hz, period = 128 frames, buffer = 2 periods
nperiods = 2 for capture
nperiods = 2 for playback
11:13:00.906 Server configuration saved to "/home/appleboy/.jackdrc".
11:13:00.907 Statistics reset.
11:13:00.912 Client activated.
11:13:00.930 Audio connection change.
11:13:00.933 Audio connection graph change.
11:13:00.934 XRUN callback (1).
11:13:00.934 XRUN callback (2).
subgraph starting at qjackctl-26131 timed out (subgraph_wait_fd=10,
status = 0, state = Triggered)
**** alsa_pcm: xrun of at least 0.696 msecs
**** alsa_pcm: xrun of at least 10.556 msecs
cannot lock down memory for RT thread (Cannot allocate memory)
cannot use real-time scheduling (FIFO at priority 9) [for thread
1082132816, from thread 1082132816] (1: Operation not permitted)


why is it that RT still gives me the memory error?

Kyle
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2-ecc0.1.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFES8QQVFIipMnXxfYRAkNKAJ9lfTI/TsqUfypfmm/wsDr6aDi8OQCeP5Ca
X6kdsZEyllySW8mGJ/ucUog=
=lc4K
-----END PGP SIGNATURE-----
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] catch 22 with realtime-lsm and commoncap (capability dependency) modules

[Mark Knecht]

The capabilities module was for 2.4 series kernel only. To get
realtime performance with 2.6 you only need realtime-lsm.

Load realtime-lsm then, with a user account that is part of your
realtime group, start Jack using qjackctl with realtime enabled on the
setup page.

Hope this helps,
Mark

On 4/23/06, Kyle Lutze <kyle@randomvoids.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I'm trying to load both realtime-lsm and capability, but I can only load
> one. the error I get is:
>
> FATAL: Error inserting realtime
> (/lib/modules/2.6.16-gentoo-r1-apple1/extra/realtime.ko): Invalid module
> format
>
> now if I load realtime first, and then try to load capability I get
>
> WARNING: Error inserting commoncap
> (/lib/modules/2.6.16-gentoo-r1-apple1/kernel/security/commoncap.ko):
> Invalid module format
> FATAL: Error inserting capability
> (/lib/modules/2.6.16-gentoo-r1-apple1/kernel/security/capability.ko):
> Invalid argument
>
> I know commoncap is the culprit, by why?
>
> dmesg output:
> realtime: exports duplicate symbol cap_vm_enough_memory (owned by commoncap)
>
> Realtime LSM initialized (group 18, mlock=1)
> commoncap: exports duplicate symbol cap_vm_enough_memory (owned by realtime)
> Failure registering capabilities with primary security module.
>
>
> I would try and fix it myself, but google showed nothing when just
> searching for "exports duplicate symbol cap_vm_enough_memory."
> any ideas?
>
> /etc/modules.d/realtime file:
> options realtime mlock=1 gid=18
>
>
>
> thanks,
> Kyle
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2-ecc0.1.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFES8KCVFIipMnXxfYRAsC+AKCGB3bPqytW9T1RCVQW+fPBg3Hg9QCghfRx
> eusfIctjpWk/vyXGzVpBJP4=
> =JpA0
> -----END PGP SIGNATURE-----
> --
> gentoo-amd64@gentoo.org mailing list
>
>

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] catch 22 with realtime-lsm and commoncap (capability dependency) modules

[Kyle Lutze]

Mark Knecht wrote:
> The capabilities module was for 2.4 series kernel only. To get
> realtime performance with 2.6 you only need realtime-lsm.
> 
> Load realtime-lsm then, with a user account that is part of your
> realtime group, start Jack using qjackctl with realtime enabled on the
> setup page.
> 
> Hope this helps,
> Mark
> 

that's interesting to know, but I still have the other issue when
realtime-lsm is loaded

cannot lock down memory for RT thread (Cannot allocate memory)
cannot use real-time scheduling (FIFO at priority 9) [for thread
1082132816, from thread 1082132816] (1: Operation not permitted)

and that's with realtime selected in qjackctl.

so what took the place of capabilities in 2.6?

Kyle
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] catch 22 with realtime-lsm and commoncap (capability dependency) modules

[Mark Knecht]

On 4/23/06, Kyle Lutze <kyle@randomvoids.com> wrote:
> Mark Knecht wrote:
> > The capabilities module was for 2.4 series kernel only. To get
> > realtime performance with 2.6 you only need realtime-lsm.
> >
> > Load realtime-lsm then, with a user account that is part of your
> > realtime group, start Jack using qjackctl with realtime enabled on the
> > setup page.
> >
> > Hope this helps,
> > Mark
> >
>
> that's interesting to know, but I still have the other issue when
> realtime-lsm is loaded
>
> cannot lock down memory for RT thread (Cannot allocate memory)
> cannot use real-time scheduling (FIFO at priority 9) [for thread
> 1082132816, from thread 1082132816] (1: Operation not permitted)

Nominally this would mean that either

1) realtime-lsm isn't really loaded
2)  there isn't enough memory to lock down
3) the user is not part of the realtime group

We need to investigate how you built Jack, how Jack is using memory &
how you're running Jack. Here's some stuff that's probably important:

lightning ~ # emerge -pv jack-audio-connection-kit

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild   R   ] media-sound/jack-audio-connection-kit-0.100.7-r1 
+alsa (-altivec) -caps (-coreaudio) -debug -doc +jack-tmpfs (-mmx)
-netjack -oss -portaudio +sndfile (-sse) 22 kB

Total size of downloads: 22 kB
lightning ~ #


lightning ~ # lsmod
Module                  Size  Used by
<SNIP>
realtime                9672  0
<SNIP>
lightning ~ #

lightning ~ # modinfo realtime
filename:       /lib/modules/2.6.16-gentoo-r2/extra/realtime.ko
license:        GPL
description:    Realtime Capabilities Security Module
vermagic:       2.6.16-gentoo-r2 preempt gcc-3.4
license:        GPL
description:    Standard Linux Common Capabilities Security Module
depends:
vermagic:       2.6.16-gentoo-r2 preempt gcc-3.4
parm:           any: grant realtime privileges to any process. (int)
parm:           gid: the group ID with access to realtime privileges. (int)
parm:           mlock: enable memory locking privileges. (int)
lightning ~ #

lightning ~ # cat /etc/modules.autoload.d/kernel-2.6
# /etc/modules.autoload.d/kernel-2.6:  kernel modules to load when system boots.
#
# Note that this file is for 2.6 kernels.
#
# Add the names of modules that you'd like to load when the system
# starts into this file, one per line.  Comments begin with # and
# are ignored.  Read man modules.autoload for additional details.

# For example:
# 3c59x
#fglrx
radeon
snd-intel8x0
snd-hdsp
ieee1394
ohci1394
sbp2 serialize_io=0
realtime gid=600 any=1
lightning ~ #

lightning ~ # cat /etc/fstab | grep jack
none                    /tmp/jack       tmpfs           defaults        0 0
lightning ~ #

>From my kernel config:

#
# Security options
#
# CONFIG_KEYS is not set
CONFIG_SECURITY=y
# CONFIG_SECURITY_NETWORK is not set
CONFIG_SECURITY_CAPABILITIES=m
# CONFIG_SECURITY_ROOTPLUG is not set
# CONFIG_SECURITY_SECLVL is not set


>
> and that's with realtime selected in qjackctl.
>
> so what took the place of capabilities in 2.6?

LSM, and with it realtime-lsm

- Mark

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] catch 22 with realtime-lsm and commoncap (capability dependency) modules

[Kyle Lutze]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

re-emerging jack-audio-connection-kit with "-caps" did the trick, go
figure. everything else was perfect

on a side note, if capabilities was replaced by realtime and lsm, why is
capabilities still in the 2.6 kernel?

Kyle
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2-ecc0.1.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFETASCVFIipMnXxfYRAuy5AJwIxnefdhRsUgyFZw8UN2reOT7USACgl1jY
mtYxZz1v38pZ7oGoTc7fIY0=
=Uf6s
-----END PGP SIGNATURE-----
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] catch 22 with realtime-lsm and commoncap (capability dependency) modules

[Mark Knecht]

On 4/23/06, Kyle Lutze <kyle@randomvoids.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> re-emerging jack-audio-connection-kit with "-caps" did the trick, go
> figure. everything else was perfect
>
> on a side note, if capabilities was replaced by realtime and lsm, why is
> capabilities still in the 2.6 kernel?
>
> Kyle

Kyle,
   Glad you have it working now. I didn't think the caps flag made any
difference. I guess the ebuild could be improved to check that.

   I think there are multiple 'capabilites' features in the kernel.
realtime operation for Jack was just one way to make Jack work at the
time which isn't used anymore. Don't ask me why. I'm a grunt.

   On a side note, now that you have realtime-lsm working be aware
that it too is going away in favor of using PAM instead. Unfortunately
there has been no developer work done et for Gentoo to get PAM up to
the level it needs to be to solve this problem with future kernels.
you might consider adding your name to one of the Bugzilla requests to
get PAM updated for realtime operation:

http://bugs.gentoo.org/show_bug.cgi?id=101766

or

http://bugs.gentoo.org/show_bug.cgi?id=87577

there is an experiemental ebuild which I won't be testing anytime soon
as I wouldn't know what to do if there was a failure.

Cheers,
Mark

-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: catch 22 with realtime-lsm and commoncap (capability dependency) modules

[Duncan]

Kyle Lutze posted <444C0482.4090408@randomvoids.com>, excerpted below,  on
Sun, 23 Apr 2006 15:49:38 -0700:

> re-emerging jack-audio-connection-kit with "-caps" did the trick, go
> figure. everything else was perfect
> 
> on a side note, if capabilities was replaced by realtime and lsm, why is
> capabilities still in the 2.6 kernel?

I'm not familiar with the 2.4 capacities module and how it worked, so
can't answer that aspect of the question.  However, in kernel 2.6, there's
the Linux Security Module (LSM) framework.  It's designed to expose the
necessary kernel hooks for any of several different security module
approaches in a pluggable way, so any of several modules can be enabled to
take advantage of it.

In 2.6, the capacities module is implemented using LSM, designed to plug
into LSM and to provide the "traditional" Linux security implementation. 
Apparently, realtime-lsm is a second available plugin.  IIRC there's at
least a third as well, the BSD audit security framework, and I believe I
read that SELinux has a module too, tho for all I know it uses the BSD
audit module, perhaps with a few modifications, not its own separate
module.

It shouldn't therefore be entirely surprising that realtime-lsm and
capacities conflict, as they are probably fighting for control of the same
thing.  Is it possible to use two different LSMs together in any case?  I
don't know, but it's evident that there's a conflict here.  It appears you
can use one or the other but not both at the same time.  You plug in one,
and it takes at least part of the interface the other one would plug
into, so you can't plug in the other.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: catch 22 with realtime-lsm and commoncap (capability dependency) modules

[Kyle Lutze]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Duncan wrote:
> Kyle Lutze posted <444C0482.4090408@randomvoids.com>, excerpted below,  on
> Sun, 23 Apr 2006 15:49:38 -0700:
> 
>> re-emerging jack-audio-connection-kit with "-caps" did the trick, go
>> figure. everything else was perfect
>>
>> on a side note, if capabilities was replaced by realtime and lsm, why is
>> capabilities still in the 2.6 kernel?
> 
> I'm not familiar with the 2.4 capacities module and how it worked, so
> can't answer that aspect of the question.  However, in kernel 2.6, there's
> the Linux Security Module (LSM) framework.  It's designed to expose the
> necessary kernel hooks for any of several different security module
> approaches in a pluggable way, so any of several modules can be enabled to
> take advantage of it.
> 
> In 2.6, the capacities module is implemented using LSM, designed to plug
> into LSM and to provide the "traditional" Linux security implementation. 
> Apparently, realtime-lsm is a second available plugin.  IIRC there's at
> least a third as well, the BSD audit security framework, and I believe I
> read that SELinux has a module too, tho for all I know it uses the BSD
> audit module, perhaps with a few modifications, not its own separate
> module.
> 
> It shouldn't therefore be entirely surprising that realtime-lsm and
> capacities conflict, as they are probably fighting for control of the same
> thing.  Is it possible to use two different LSMs together in any case?  I
> don't know, but it's evident that there's a conflict here.  It appears you
> can use one or the other but not both at the same time.  You plug in one,
> and it takes at least part of the interface the other one would plug
> into, so you can't plug in the other.
> 

ahh the downfall of linux, people can't decide on one thing, so they
make two seperate ones, programs you use at the same time require both,
you get the shaft. Argg!!!

Kyle
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2-ecc0.1.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFETEtbVFIipMnXxfYRAiLLAKCBq1djFyxTymPK992BGFL1zOgwrgCfUTv9
rDbAKAQtCy64TvKmVS6uFP4=
=RlMf
-----END PGP SIGNATURE-----
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: catch 22 with realtime-lsm and commoncap (capability dependency) modules

[Mark Knecht]

On 4/23/06, Kyle Lutze <kyle@randomvoids.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Duncan wrote:
> >
> > It shouldn't therefore be entirely surprising that realtime-lsm and
> > capacities conflict, as they are probably fighting for control of the same
> > thing.  Is it possible to use two different LSMs together in any case?  I
> > don't know, but it's evident that there's a conflict here.  It appears you
> > can use one or the other but not both at the same time.  You plug in one,
> > and it takes at least part of the interface the other one would plug
> > into, so you can't plug in the other.
> >
>
> ahh the downfall of linux, people can't decide on one thing, so they
> make two seperate ones, programs you use at the same time require both,
> you get the shaft. Argg!!!
>
> Kyle

Just keep in mind that LSM **IS** going away. It's not an IF, it's a WHEN.

Gentoo needs proper modern PAM support. Let's hope the developers will
address this before we audio folks get stuck and have to find other
solutions. There is a test ebuild for PAM out there but it's not part
of portage.

If anybody has need of newer version of PAM please let the devs know.

Cheers,
Mark

-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Re: catch 22 with realtime-lsm and commoncap (capability dependency) modules

[Duncan]

Mark Knecht posted
<5bdc1c8b0604232127m36e41816hd387e5da9e620d3e@mail.gmail.com>, excerpted
below,  on Sun, 23 Apr 2006 21:27:17 -0700:

> Just keep in mind that LSM **IS** going away. It's not an IF, it's a
> WHEN.

??  LSM -- the kernel Linux Security Module framework, or realtime-lsm (as
your previous post implied) specifically?

As far as I was aware, there had been discussions of eliminating the LSM
plugin framework entirely, if nothing else was merged into mainline that
used it.  I believe the traditional capabilities module was the only thing
in mainline that really used it.  (The other option there, BSD security
levels, was apparently only using it as a convenience, but could just as
easily do without.  The rootplug module was a simple coding sample, little
more.)

However, I had believed the discussion had been shelved, after putting
people on notice that LSM /might/ be removed, until some later date,
giving folks time in the meantime to propose additional plugins and make
their case for inclusion in mainline.  (The idea being that if it's not in
mainline, it's a patch anyway, and they might as well patch the
functionality now being maintained with LSM into it at the same time, if
they use it.)

Looking at the config for 2.6.17-rc2, I see socket and networking security
hooks as another option under LSM, which I don't remember from before. 
Perhaps this has been added as a result of the previous discussion.

Anyway, to say that LSM IS going away, WHEN, not IF, is a significantly
stronger statement than I had yet seen.  Thus, clarification is needed. 
Are/were you just referring to realtime-lsm, as your previous post
implied, and you just mis-typed here, or is there a definitive LSM IS
going away, that I wasn't aware of?  As far as I knew, it was an open
question, and indeed, as much designed to try to get folks to push their
LSM modules (of which there were several outside of mainline) into
mainline, as it was a question of killing mainline LSM entirely.  A
strong statement such as the above needs stronger than average support,
references and/or at least supporting background information.

So... spill the beans!  =8^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Re: catch 22 with realtime-lsm and commoncap (capability dependency) modules

[Mark Knecht]

On 4/23/06, Duncan <1i5t5.duncan@cox.net> wrote:
> Mark Knecht posted
> <5bdc1c8b0604232127m36e41816hd387e5da9e620d3e@mail.gmail.com>, excerpted
> below,  on Sun, 23 Apr 2006 21:27:17 -0700:
>
> > Just keep in mind that LSM **IS** going away. It's not an IF, it's a
> > WHEN.
>
> ??  LSM -- the kernel Linux Security Module framework, or realtime-lsm (as
> your previous post implied) specifically?
>
> As far as I was aware, there had been discussions of eliminating the LSM
> plugin framework entirely, if nothing else was merged into mainline that
> used it.  I believe the traditional capabilities module was the only thing
> in mainline that really used it.  (The other option there, BSD security
> levels, was apparently only using it as a convenience, but could just as
> easily do without.  The rootplug module was a simple coding sample, little
> more.)
>
> However, I had believed the discussion had been shelved, after putting
> people on notice that LSM /might/ be removed, until some later date,
> giving folks time in the meantime to propose additional plugins and make
> their case for inclusion in mainline.  (The idea being that if it's not in
> mainline, it's a patch anyway, and they might as well patch the
> functionality now being maintained with LSM into it at the same time, if
> they use it.)

There have been a bunch of conversations on this subject last week on
the LKML. As best I understand them it seem that everyone is pretty
much in agreement that it's going away completely. the same things can
be done with PAM so they see no reason to carry it forward. I don't
know if it's going in 2.6.17 or 2.6.18 but it sounds like it will go
soon. A few of the audio folks smarter than seem to agree.

the issue we have here in Gentoo land is that the correct version of
PAM is 0.80 or later and that has not been available in portage,
althoough I see this morning a masked version of 0.99.3.0 so it looks
like someone is starting to look after this...

>
> Looking at the config for 2.6.17-rc2, I see socket and networking security
> hooks as another option under LSM, which I don't remember from before.
> Perhaps this has been added as a result of the previous discussion.
>
> Anyway, to say that LSM IS going away, WHEN, not IF, is a significantly
> stronger statement than I had yet seen.  Thus, clarification is needed.
> Are/were you just referring to realtime-lsm, as your previous post
> implied, and you just mis-typed here, or is there a definitive LSM IS
> going away, that I wasn't aware of?  As far as I knew, it was an open
> question, and indeed, as much designed to try to get folks to push their
> LSM modules (of which there were several outside of mainline) into
> mainline, as it was a question of killing mainline LSM entirely.  A
> strong statement such as the above needs stronger than average support,
> references and/or at least supporting background information.
>
> So... spill the beans!  =8^)

Hope they are spilt correctly.

- Mark
>
> --
> Duncan - List replies preferred.   No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master."  Richard Stallman in
> http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html
>
>
> --
> gentoo-amd64@gentoo.org mailing list
>
>

-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Re: Re: catch 22 with realtime-lsm and commoncap (capability dependency) modules

[Duncan]

Mark Knecht posted
<5bdc1c8b0604241008y6cbdd79dkde18bd535f8b482c@mail.gmail.com>, excerpted
below,  on Mon, 24 Apr 2006 10:08:59 -0700:

> On 4/23/06, Duncan <1i5t5.duncan@cox.net> wrote:
>> Mark Knecht posted
>> <5bdc1c8b0604232127m36e41816hd387e5da9e620d3e@mail.gmail.com>,
>> excerpted below,  on Sun, 23 Apr 2006 21:27:17 -0700:
>>
>> > Just keep in mind that LSM **IS** going away. It's not an IF, it's a
>> > WHEN.
>>
>> ??  LSM -- the kernel Linux Security Module framework, or realtime-lsm
>> (as your previous post implied) specifically?
>>
>> As far as I was aware, there had been discussions of eliminating the
>> LSM plugin framework entirely, if nothing else was merged into mainline
>> that used it. [] However, I had believed the discussion had been
>> shelved, after putting people on notice that LSM /might/ be removed,
>> until some later date[.]
> 
> There have been a bunch of conversations on this subject last week on
> the LKML. As best I understand them it seem that everyone is pretty much
> in agreement that it's going away completely. the same things can be
> done with PAM so they see no reason to carry it forward. I don't know if
> it's going in 2.6.17 or 2.6.18 but it sounds like it will go soon. A few
> of the audio folks smarter than seem to agree.

Something that big would have to go into (come out of) an -rc1.  They
wouldn't do it beyond that, as it's too big a change.  As I mentioned,
2.6.17-rc2 still has it, so presumably a patch removing it would be
submitted for 2.6.18-rc1.  That's assuming they don't decide a six-month
or whatever notice is warranted.  Most big removals of that nature get put
on a schedule to do some months later, the idea being that one simply
can't remove a user-space interface without at least /some/ notice.

> the issue we have here in Gentoo land is that the correct version of PAM
> is 0.80 or later and that has not been available in portage, althoough I
> see this morning a masked version of 0.99.3.0 so it looks like someone
> is starting to look after this...

Given Greg KH is a big kernel dev /and/ a Gentoo dev, I don't believe he'd
let Gentoo get /too/ out of sync in that regard. 

However, there's another reason to do the 6-month notice thing, as neither
Gentoo nor any of the other big distributions will be able to stabilize an
updated replacement PAM in the ~2 month kernel release development period.
I doubt this will be in (out of) .18, either.  .19 is more reasonable.  I
expect it will be either .19 or .20 if the decision has now been
finalized.  A stable PAM replacement should be doable by that time.

Thanks for the updated info!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list