2009/11/10 Linux Kernel Podcast
AUDIO: http://media.libsyn.com/media/jcm/linux_kernel_podcast_20091110.mp3
For Tuesday, November 10th, 2009, I’m Jon Masters with a summary of today’s LKML traffic.
In today’s issue: AppArmor, Changing task UIDs, SECURITY_FILE_CAPABILITIES, and Stable tags and git workflow.
AppArmor. John Johansen posted version 3 of a 12 part patch series intended to re-implement the AppArmor security module (which was previously maintained out of tree by Novell, until it wasn’t, then seemed to die shortly after Canonical begun to support it, and now has returned in a new form in a posting from John, who is a Canonical engineer) upon the security_path hooks instead of the previous VFS hack. AppArmor is a path-based alternative to SELinux that is sometimes seen as being less complicated to setup, although this is debated. In any case, these patches seem more supportable for upstream inclusion.
Changing task UIDs. Enrico Weigelt, who is working on plan9 patches inquired as to the best way to implement plan9-style support for changing the UID of running tasks, perhaps through a new /proc entry. He then proceeded to post various replies to other threads he had not previously been involved with – amongst other things criticizing hald and dbus design, and espousing the virtues of plan9 (if only it had more users to sell us on its features?).
SECURITY_FILE_CAPABILITIES. Serge E. Hallyn posted suggesting the the Kconfig option SECURITY_FILE_CAPABILITIES be removed, specifically invalidating the case of SECURITY_FILE_CAPABILITIES=n, and meaning that such capabilities would always be enabled unless the user specified no_file_caps on system boot. The reason behind this suggestion stems from an apparent missunderstanding amonsgt a growing number of application developers that such support is always present, leading Serge to wonder if it might aswell just be by now.
Stable tags and git workflow. Ingo Molnar posted an RFC concerning stable tree git commit workflow. He noted that that previously, he would have to email (cherry pick) the specific pre-requisite dependencies for any stable patch forwarded to the stable team (or wait for an email when things didn’t apply to the stable tree), but felt that this could be optimized. So, Ingo has begun adding comments on “CC” lines in the patch indicating additional commits that should be included, e.g. “# .32.x:
Finally today, Chris Friesen had asked about correct use of IANA-registered ports on systems running sunrpc. Specifically, the RPC implementation as used by NFS can make use of ports that are reserved for other services, if a range has not been set aside ahead of time (and even then, it’s not optimal if you really want to run every service). But Trond Myklebust asked the obvious: “The people who are trying to run absolutely all IANA registered services on a single Linux machine that is also trying to run as an NFS client may have a problem, but then again, how many setups do you know who are trying to do that?”. The answer, one assumes, is less than one.
In today’s announcements: 2.6.31.6-rt19. Thomas Gleixner announced preempt-rt patch series release number rt19 for the 2.6.31.6 stable kernel. This was mostly a forward port to the latest stable tree, but also contains a missing pre-emption point in ksoftirqd. The patches are avaialable in the usual locations, amongst them: http://www.kernel.org/pub/linux/kernel/projects/rt.
The latest kernel release is 2.6.32-rc6.
Stephen Rothwell posted a linux-next tree for November 10th. Since Monday, there was a new sysctl tree from Eric W. Biederman that contains only the generic compat_sys_sysctl patches now that binary sysctls are going away. The net tree lost both a conflict and build failure, the wireless tree still has a build failure, and the trivial tree lost a conflict. Stephen reports the sub-tree count at 146, but that is incongruent with the new tree.
That’s a summary of today’s Linux Kernel Mailing List traffic, for further information visit www.kernel.org. I’m Jon Masters.











You know, Enrico Weigelt may not be wrong concerning DBUS and HAL. Look at HAL, it is being depreciated and replacaed by various piece of software ( device-disk, libudev, … ). And I guess that not too far away in the future, we will hear that some people want to replace DBUS …