I am a complete noob and only follow the lists out of interest. I am also very young, so please forgive my impertinence. Thanks Thomas for your work!! Just my 2c: On 03/27/2014 08:34 PM, Nicolas Iooss wrote: > 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". Because of this: "Arch Linux defines simplicity as without unnecessary additions, modifications, or complications, and provides a lightweight UNIX-like base structure that allows an individual user to shape the system according to their own needs. In short: an elegant, minimalist approach."[1] The main kernel *should* be simple *_by that definition_*. From my (limited) point of view, the default in Arch should always be the most lightweight, practical solution. This is not RHEL or Ubuntu, we have a very limited workforce and want to be simple. I hope that I didn't offend anybody. > 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 > Cheers, Bennett [1]source: https://wiki.archlinux.org/index.php/The_Arch_Way
Attachment:
signature.asc
Description: OpenPGP digital signature
