FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS Development

 
 
LinkBack Thread Tools
 
Old 10-25-2011, 04:56 PM
Karanbir Singh
 
Default cr/SRPMS/Packages/ empty

On 10/25/2011 01:18 PM, Tetsuo Handa wrote:
> Just wanted to rebuild with TOMOYO enabled. To do so, I wanted to know
> what modification is required for reusing upstream packages.

It would be great to have that in the CentOS Plus kernel

- KB
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 10-25-2011, 05:00 PM
Johnny Hughes
 
Default cr/SRPMS/Packages/ empty

On 10/25/2011 08:14 AM, me@tdiehl.org wrote:
> On Tue, 25 Oct 2011, Karanbir Singh wrote:
>
>> On 10/24/2011 10:53 PM, Tetsuo Handa wrote:
>>>>> Please, put at least some SRPMS here Most interesting are net-base:
>>>>> kernel, iptables, tc, ifconfig, ppp, rp-pppoe and all such - people are
>>>>> updating their patches for 6.1 out there (I'm among them) and it may be
>>>>> nice to have sources to know what awaits us.
>>> I'm waiting for kernel-2.6.32-131.17.1.el6.src.rpm .
>>
>> We have enough ( but barely enough ) space on the mirrors for
>> 6.0/cr/SRPMS; however that would then mean that we no longer have enough
>> space to get 6.1 on there.
>>
>> So just to keep with the theme of things, what is the feeling if I were :
>> - to drop the CR/SRPMS into vault.c.o
>> - add a .repo stanza into the centos-release-cr rpm with a [sources]
>> pointing to the right place
>
> I think that is a good idea. It should not matter to anyone where the srpms are
> physically located as long as they are accessible.
>
> In addition, given that the sprms used to build most of the distro are
> unmodified from the upstream versions, do you even need to distribute
> them? Since I am not a lawyer I do not know the answer but it would seem
> to me that if you made the srpms you modify available that would be good
> enough.

You have to provide your own copies and that is clearly called out in
the GPL. The reason is that SOMEONE ELSE might go out of business, etc.

Also, the "someone else" only needs to provide the Source to their
"customers/users" ... so in the case of Red Hat, they could, for
example, put those SRPMS as only available via an RHN account. That
would leave CentOS users in a bad place.

This is the reason that you are responsible to provide your own source
code ... which we will. Now, if 2 companies have a relationship ...
like Fedora and Red Hat, then one could provide the sources for both, etc.

>
> I am sure some lawyer wannabee will complain about this. People always seem to
> find something to whine about but if you could do that it would save a bunch
> of disk space. Which is a good thing IMO.
>
> Just my $.02
>
> Regards,
>


_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 10-25-2011, 09:42 PM
Tetsuo Handa
 
Default cr/SRPMS/Packages/ empty

Karanbir Singh wrote:
> On 10/25/2011 01:18 PM, Tetsuo Handa wrote:
> > Just wanted to rebuild with TOMOYO enabled. To do so, I wanted to know
> > what modification is required for reusing upstream packages.
>
> It would be great to have that in the CentOS Plus kernel

I'd like to. But enabling TOMOYO (i.e. changing to CONFIG_SECURITY_PATH=y)
triggers changes in "struct security_operations" that results in kernel ABI
changes. If I recall correctly, CentOS Plus kernel does not accept kernel
config changes that changes kernel ABI.
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 10-25-2011, 10:02 PM
Akemi Yagi
 
Default cr/SRPMS/Packages/ empty

On Tue, Oct 25, 2011 at 2:42 PM, Tetsuo Handa
<from-centos@i-love.sakura.ne.jp> wrote:
> Karanbir Singh wrote:
>> On 10/25/2011 01:18 PM, Tetsuo Handa wrote:
>> > Just wanted to rebuild with TOMOYO enabled. To do so, I wanted to know
>> > what modification is required for reusing upstream packages.
>>
>> It would be great to have that in the CentOS Plus kernel
>
> I'd like to. But enabling TOMOYO (i.e. changing to CONFIG_SECURITY_PATH=y)
> triggers changes in "struct security_operations" that results in kernel ABI
> changes. If I recall correctly, CentOS Plus kernel does not accept kernel
> config changes that changes kernel ABI.

Yes, that is correct. Anything that causes kABI incompatibility cannot
be implemented in the cplus kernel.

Akemi
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 10-26-2011, 09:39 AM
Karanbir Singh
 
Default cr/SRPMS/Packages/ empty

On 10/25/2011 10:42 PM, Tetsuo Handa wrote:
>> It would be great to have that in the CentOS Plus kernel
>
> I'd like to. But enabling TOMOYO (i.e. changing to CONFIG_SECURITY_PATH=y)
> triggers changes in "struct security_operations" that results in kernel ABI
> changes. If I recall correctly, CentOS Plus kernel does not accept kernel
> config changes that changes kernel ABI.

so, lets make room for a kernel-<ver>-<rel>.tomoyo perhaps. Is that
config option the only real change needed ?

Over a period of time, how are RH patches likely to impact this ?

- KB
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 10-26-2011, 01:51 PM
Tetsuo Handa
 
Default cr/SRPMS/Packages/ empty

Karanbir Singh wrote:
> so, lets make room for a kernel-<ver>-<rel>.tomoyo perhaps. Is that
> config option the only real change needed ?

Thanks. CONFIG_SECURITY_PATH=y and CONFIG_SECURITY_TOMOYO=y are needed.

> Over a period of time, how are RH patches likely to impact this ?

Distributor's patches unlikely break CONFIG_SECURITY_TOMOYO because TOMOYO 2.x
is in-tree. However, RH heavily backports features from later kernels to RHEL.
I guess RH would backport RCU path walk patchset (which breaks TOMOYO 2.2) to
RHEL 6. If such backport happens, kernel-<ver>-<rel>.tomoyo can no longer be
provided without kernel patches.

TOMOYO 2.x is already enabled in Ubuntu, Debian, openSUSE etc. But RH would be
the last distribution that enables TOMOYO because RH drives SELinux. I proposed
TOMOYO 2.x for Fedora but was rejected.

I'm providing 2 alternatives. One is TOMOYO 1.x (out of tree patches that
require recompilation of kernel source package but can keep kernel ABI) and the
other is AKARI (subset of TOMOYO 1.x but is a loadable kernel module).
http://akari.sourceforge.jp/comparison.html

Given above circumstances/risks, do we think we should make room for a
kernel-<ver>-<rel>.tomoyo ?
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 10-26-2011, 04:46 PM
Akemi Yagi
 
Default cr/SRPMS/Packages/ empty

On Wed, Oct 26, 2011 at 6:51 AM, Tetsuo Handa
<from-centos@i-love.sakura.ne.jp> wrote:

> I'm providing 2 alternatives. One is TOMOYO 1.x (out of tree patches that
> require recompilation of kernel source package but can keep kernel ABI) and the
> other is AKARI (subset of TOMOYO 1.x but is a loadable kernel module).
> http://akari.sourceforge.jp/comparison.html

I checked the config options required for AKARI. Of the 5 options
listed, one is not set in the current EL6 kernel:

# CONFIG_SECURITY_PATH is not set

You mentioned CONFIG_SECURITY_PATH is the one that breaks the kABI.
But TOMOYO 1.x would not?

Akemi
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 10-26-2011, 09:49 PM
Tetsuo Handa
 
Default cr/SRPMS/Packages/ empty

Akemi Yagi wrote:
> > I'm providing 2 alternatives. One is TOMOYO 1.x (out of tree patches that
> > require recompilation of kernel source package but can keep kernel ABI) and the
> > other is AKARI (subset of TOMOYO 1.x but is a loadable kernel module).
> > http://akari.sourceforge.jp/comparison.html
>
> I checked the config options required for AKARI. Of the 5 options
> listed, one is not set in the current EL6 kernel:
>
> # CONFIG_SECURITY_PATH is not set
>
> You mentioned CONFIG_SECURITY_PATH is the one that breaks the kABI.

CONFIG_SECURITY_PATH is the one that is mandatory for TOMOYO 2.x but breaks the
kABI. But CONFIG_SECURITY_PATH is optional for AKARI. AKARI was designed to be
usable on RHEL kernels without changing kernel config or patching to source.

> But TOMOYO 1.x would not?

TOMOYO 1.x does not need CONFIG_SECURITY_PATH because TOMOYO 1.x adds a new set
of hooks similar to CONFIG_SECURITY_PATH. Thus, the kABI is preserved but
TOMOYO 1.x needs patching to source.
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 10-26-2011, 10:07 PM
Akemi Yagi
 
Default cr/SRPMS/Packages/ empty

On Wed, Oct 26, 2011 at 2:49 PM, Tetsuo Handa
<from-centos@i-love.sakura.ne.jp> wrote:
> Akemi Yagi wrote:
>> > I'm providing 2 alternatives. One is TOMOYO 1.x (out of tree patches that
>> > require recompilation of kernel source package but can keep kernel ABI) and the
>> > other is AKARI (subset of TOMOYO 1.x but is a loadable kernel module).
>> > http://akari.sourceforge.jp/comparison.html
>>
>> I checked the config options required for AKARI. Of the 5 options
>> listed, one is not set in the current EL6 kernel:
>>
>> # CONFIG_SECURITY_PATH is not set
>>
>> You mentioned CONFIG_SECURITY_PATH is the one that breaks the kABI.
>
> CONFIG_SECURITY_PATH is the one that is mandatory for TOMOYO 2.x but breaks the
> kABI. But CONFIG_SECURITY_PATH is optional for AKARI. AKARI was designed to be
> usable on RHEL kernels without changing kernel config or patching to source.

I see. Then the AKARI kernel module will be a good (perfect?)
candidate for ELRepo.

>> But TOMOYO 1.x would not?
>
> TOMOYO 1.x does not need CONFIG_SECURITY_PATH because TOMOYO 1.x adds a new set
> of hooks similar to CONFIG_SECURITY_PATH. Thus, the kABI is preserved but
> TOMOYO 1.x needs patching to source.

In this case, the cplus kernel can accommodate TOMOYO 1.x. Can you
think of any reason it cannot? Anything else to consider?

On a not so important subject, is TOMOYO written as 友代, and AKARI as 明 ? 灯り ?

Akemi
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 10-27-2011, 03:57 AM
Tetsuo Handa
 
Default cr/SRPMS/Packages/ empty

Tetsuo Handa wrote:
> CONFIG_SECURITY_PATH is the one that is mandatory for TOMOYO 2.x but breaks the
> kABI.

My apologies. I was misunderstanding. I was assuming that making changes in
"struct security_operations" breaks the kABI. But it seems it does not.

I've just rebuilt kernel-2.6.32-131.17.1.el6.i686.rpm with TOMOYO 1.x/2.x.
rpmbuild with kabi checks enabled did not fail.

The only difference in symvers-2.6.32-131.12.1.el6.i686.gz between stock
CentOS's kernel and CentOS + TOMOYO 1.8 kernel was

+ 0x0b6d773e ccsecurity_ops vmlinux EXPORT_SYMBOL

. The only difference in symvers-2.6.32-131.12.1.el6.i686.gz between stock
CentOS's kernel and CentOS + TOMOYO 2.2 (CONFIG_SECURITY_PATH=y +
CONFIG_SECURITY_TOMOYO=y) kernel was

+ 0xfc4d6f3e security_path_mknod vmlinux EXPORT_SYMBOL

. TOMOYO added one new symbol but didn't change existing symbols.

Akemi Yagi wrote:
> In this case, the cplus kernel can accommodate TOMOYO 1.x. Can you
> think of any reason it cannot? Anything else to consider?

Does the cplus kernel accept source code not within RHEL's kernel SRPM?
I thought the cplus kenrel does not. If it doesn't, TOMOYO 2.2 is OK for now
but will require build fix patch when RCU path walk patchset is backported.

> On a not so important subject, is TOMOYO written as 友代, and AKARI as 明 ? 灯り ?

TOMOYO is 知世 from Card Captor Sakura, AKARI is 灯里 from ARIA.
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 

Thread Tools




All times are GMT. The time now is 08:50 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org