Messages in this thread | | | From | Bernd Eckenfels <> | Subject | Re: secure computing for 2.6.7 | Date | Sun, 01 Aug 2004 16:55:47 +0200 |
| |
In article <20040801102231.GB6295@dualathlon.random> you wrote: > /proc/sys/kernel/security_sequence [1] or anything like that that we > could increase every time we fix a kernel bug (note, it's not mandatory > to increase it every time, and we could increase it even weeks after the > bug has been fixed after somebody ask for it, and it would still work > fine)
Hmm.. yes, kind of patchlevel/build number.
I feel that you miss a solution for different branches, backporting and partial fixes. Since that way it can only work for the official branches of the kernel, it would be enough to check the minor number.
Personally I think it is better to keep that in the utsname.release. If you realy want to have an integer, then add it for easy parsing and allow it to have multiple parallel issuers:
For example like:
2.6.9_XXX(linux26.3501,MM.123)
where this has applied fix 3501 in the 2.6 branch and 123 according to vendor MM, so you do not need to understand vendors XXX schema. However I am not sure if you are willing to accept the fact, that backporters will then raise the level to a value you will only expect for more recent versions, i.e.:
2.6.9(linux26.3501) -> security bug1 is discoverd and fixed 2.6.10pre1(linux26.3502) -> security bug2 is discoverd and fixed -> features are added 2.6.10(linux26.3503)
Now somebody decides to backport the bug1 fix:
2.6.9-2(linux26.3502)
and the bug2 fix:
2.6.9-3(linux26.3503) <- is level 3503 but does not have all 2.6.10 features?!
And it gets even more hairy: if only the bug2 fix is backported, how can an application state that it needs that (without impliciteley also reling on bug1 to be fixed)
Greetings Bernd -- eckes privat - http://www.eckes.org/ Project Freefire - http://www.freefire.org/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |