2014-03-27 16:31 GMT+01:00 Bigby James <bigby.james@xxxxxxxxxxxx>: > On Thu, Mar 27, 2014 at 09:07:23AM +0100, Nicolas Iooss wrote: >> >> Here are three arguments to motivate my disagreement. >> >> * First, removing LSM support makes it difficult for users to test >> LSM. Before 3.13 kernel, users needed to recompile their kernel (or to >> install linux-selinux AUR package) to be able to use SELinux. This is >> a hard first step and I know too many people who thinks "I don't want >> to recompile my kernel as I've already done magical things to make my >> graphic card works and I don't want to break my fragile config". Now >> people just needs to install packages (from unofficial repos or from >> the AUR) as described in the wiki [4] and reboot to start using >> SELinux. >> * Second, it's possible to compile things which are disabled at >> runtime. For example, I don't need to compile the kernel without IPv4 >> to test what breaks when running a non-IPv4 kernel, I only need to add >> a boot parameter and/or a file in /etc/sysctl.d/. It's the same thing >> for LSM. Even if they are compiled, they can be enabled/disabled with >> such runtime configuration and this config doesn't require much work. >> * Third, users who want to combine several unofficial features for >> their kernel already have to do weird things. For example, I'm using a >> grsec kernel with SELinux. A few months ago, there were linux-grsec >> and linux-selinux in the AUR but no package which provided both. Hence >> I needed to build a custom package to have both. Now, the next time >> linux-grsec's maintainer will sync its config with the official repo, >> SELinux will be available in this package (unless I've missed >> something) and I'll no longer need to build my custom kernel. > > As a lowly end-user, I'll have to disagree with you. The bulk of your reasoning > comes down to "*I* use it, so don't take it away from me." But your case is > hardly representative; I highly doubt that the typical desktop user (that is, > the typical Arch user) makes use of SELinux or its cohorts; no doubt there are > people running Arch servers that use it, but again that's not representative of > the community at large, in which many people just install Arch on their laptops > and desktops for everyday production and entertainment use. > > When I build a custom kernel for my laptop, the LSM stuff and kernel debugging > options are the first to go, as they have absolutely no benefit for someone who > uses a computer primarily for reasearch and writing, coding and design work, web > browsing and music. They're complements for specific use-cases---server > administration (most likely when multiple users are involved) and kernel > hacking, respectively---and are of no use to anyone who doesn't partake in those > use-cases (how necessary is MAC to someone who interacts with and monitors a > single machine all day?). Besides, as you've said, you already need to build the > userspace utilities from source (because not too long ago, the devs voiced their > opposition to maintaining SELinux officially), so leaving such features in the > kernel to ease "testing" is both specious and a mismeasure of how useful or > vital they might be. Suppose the majority of people who test SELinux decide to > drop it, as seems to be the case in my (admittedly limited) observations. Of > what value, then, is the work the devs did to maintain it? > Sorry if my message sounded too much as "I use it so I want other people to make my life easier". That was not the intended tone at all. If you need a bit more background about how I use ArchLinux, let me say I'm using it on my laptop, where I don't fear to do things that breaks my system (and if often breaks) because I have easy physical access. When I needed to set up SELinux on a server (not running Arch) a few months ago, I decided to first familiarize myself with this software on my laptop. It took me a long time before having a working system and I'm trying to reduce that time for other users who might have same ideas as I (eg. by reporting and helping fixing bugs like http://lists.gnu.org/archive/html/bug-coreutils/2014-01/msg00009.html). Of course, I'm biased when I speak of SELinux so basically I try to imagine the state of mind of "normal" people by replacing "SELinux" with "Linux containers", which I've never used and see as unneeded weight (this is a biased unmotivated statement which may be untrue). I don't know if currently to run LXC or systemd-nspawn you need to recompile your kernel, but you need at least UTS namespaces, network namespaces... and I don't know if anyone will consider disabling these features, but I expect voices to be raised if someone thinks of removing CONFIG_UTS_NS and CONFIG_NET_NS (or are such decisions expected to happen without anybody noticing?). >> That been said, I agree that having a kernel with less features would >> be good. To my mind, here are possible ways : >> >> a) Create a linux-light package with less features than the linux >> package, and don't trim linux' configuration. >> b) Rename linux as "linux-full" (as an official package) and trim linux' config. >> c) Create a package ("linux-src"?) which install the kernel sources >> and provides an easy way to customize the config before making the >> packages (with pkgbuild). Currently linux-grsec AUR package provides >> this feature by using the MENUCONFIG environment variable [5]. >> d) Don't create new packages and trim linux' config (this is your >> idea, if I understood correctly). >> >> Any of a) or b) would suits fine for me if you choose to drop LSM in >> the lighter config. >> > > I've used Arch for years now, but I can remember what it was like as a n00b. > From the perspective of someone who is new to Arch, this is grossly misleading. > Someone unfamiliar with how Arch packaging works (or a long-term Archer who > doesn't pay close enough attention to the news and mailing lists) will > conceivably reason that "linux-full" = "linux-not-broken," and "linux-light" and > "linux-src" = "I have to screw with it for two hours to get my GPU working." > They'll likely just install linux-full anyway, unaware of the distinction. > > It seems far more reasonable to me to trim the kernel to those things typical of > everyday desktop use, and trust that members of the community will maintain > those things which they find useful separately. I don't mean to be presumptuous, > but it's my understanding that the primary goal of the Arch devs and repo > maintainers is to provide a minimal, functional distribution platform that users > can utilize to craft their systems as they see fit. They don't want to cover > every imaginable use-case, but provide users with tools with which to fulfill > their own desires and needs themselves. What the devs provide in the base group, > the [core] and [extra] repos are those things most common for mundane computer > use via Linux-based operating systems. Special use cases are precisely what ABS > and the AUR are there for. > > Requiring people to build a custom kernel in order to *not have these features* > is the exact situation are already in *right now.* Asking the devs to maintain > multiple kernels just to save what I suspect is a minority---who already build > several packages from the AUR, for rarely used functionality---a little time > isn't reasonable. Moreover, while I may mistake your meaning, the list above > reads like you're asking the developers to make your preferred kernel build the > default, and reasoning that "It's no big deal, if people don't want that stuff > they can just build their own through ABS." That's not a solution at all, and > again, *it's already the case right now.* > Ok, my wording had been really bad if people understood that :( What I'm trying to do is to make things easier for other people, not myself (whatever the final decision is, I'll still use Arch in a config which is not the default), and I certainly don't want the devs to waste time doing duplicated work. The ideas of having multiple supported kernel was a bad one (and thanks for pointing that out) but I needed to ask what I asked to understand better (and to make people with similar questions as I understand better) why this thread is about "shrinking the supported kernel configuration" and not about "creating a new smaller kernel". My post was also to start thinking of what I will answer to people in a few months when they'll ask "why do I need to recompile my kernel to use SELinux? I don't have to recompile sudo to have OpenLDAP support?" (these are quite random package names). I'll answer these people that the kernel is not a package like others and that most people want a kernel as small as possible, but don't care about feature-complete packages. Thanks, Nicolas
