1 |
On 09/03/2011 04:38 PM, "Tóth Attila" wrote: |
2 |
> 2011.Szeptember 3.(Szo) 21:46 időpontban Anthony G. Basile ezt írta: |
3 |
>> It does look like the same issue again. I don't think we really solved |
4 |
>> it, but just found a workaround which you specify above. |
5 |
> |
6 |
> It's definitely back. |
7 |
> |
8 |
>> It turns out that you can compile it static and change mode upon booting |
9 |
>> by echoing values to /sys/class/net/bond0/bonding/mode. I do that on |
10 |
>> two systems running ancient 2.6.34 kernels, but this should work on |
11 |
>> 3.0.x. You can try that. |
12 |
> |
13 |
> The problem is, that if I put some echo lines in the preup phase of the |
14 |
> network setup, it returns with an error message, that the file cannot be |
15 |
> written to. After I could manually do it, it is already up, and the kernel |
16 |
> denies to modify the running interface. |
17 |
> |
18 |
> Additionally these grsec lines can be also seen in the logs. |
19 |
|
20 |
You would do the echo after networking is up. I do it during |
21 |
local_start() on bootup which is the last script run. |
22 |
|
23 |
> |
24 |
>> However, it bothers me that we don't understand what's going on. You |
25 |
>> can try disabling GRKERNSEC_MODHARDEN and rebooting to see if grsec is |
26 |
>> denying some udev trigger. But modharden should only prevent non-root |
27 |
>> processes from autoloading. I can't test on mine because they are on |
28 |
>> high availability clusters. |
29 |
> |
30 |
> Disabling MODHARDENED would definitely make the grsec messages disappear. |
31 |
> I'll try to figure out what happens regarding reading and writing the bond |
32 |
> mode during boot. |
33 |
|
34 |
Did you test? If that's the case, then we know it must be some non-root |
35 |
process trying to autoload the module and we have narrowed the |
36 |
possibilities. |
37 |
|
38 |
> |
39 |
> Compiling it in the kernel with modified defaults solves all problem, but |
40 |
> it's not a real solution. |
41 |
> |
42 |
> Thanks for your time: |
43 |
> Dw. |
44 |
|
45 |
Correct, its not a solution because we don't now what's going on. It is |
46 |
a workaround in the mean time and it is tested. |
47 |
|
48 |
-- |
49 |
Anthony G. Basile, Ph.D. |
50 |
Gentoo Linux Developer [Hardened] |
51 |
E-Mail : blueness@g.o |
52 |
GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535 |
53 |
GnuPG ID : D0455535 |