[gentoo-dev] Re: Kernel compiles and you

[Duncan]

Michał Górny posted on Wed, 04 Jul 2012 22:38:50 +0200 as excerpted:

> On Wed, 4 Jul 2012 20:06:58 +0200 Tobias Klausmann <klausman@g.o>
> wrote:
>
>> On Wed, 04 Jul 2012, Michał Górny wrote:
>> > There's a very simple yet custom solution I'm using. Shortly saying:
>> > checkout the kernel git to /usr/src/linux and chown to your user. As
>> > far as it goes, it's superior to having kernel sources installed by
>> > ebuilds.
>> >
>> > I just have to remember to do 'git fetch' from time to time and 'git
>> > merge' whenever a new version is tagged.
>>
>> It is also beyond the package manager's control. That means users who
>> want to just configure their kernel (and run point releases otherwise)
>> have to actively check for new tags/versions.
>
> True. I think that's the direction I should look into improving.
>
>> Aside from that the git tree is not exactly lightweight: my current 2.6
>> checkout weighs in at 1.4G whereas the unpacked tar is 512M.
>
> Well, that's the other problem. On the other hand, you usually have to
> have that 1G free anyway unless you intend to manually unmerge the
> previous *-sources before installing the new one. And the time needed to
> do that... git is so much faster.

I'll second the git being faster bit.  What's especially nice about it is 
that checking out and building any arbitrary tag (release or rc), or for 
that matter, doing a bisect down to an individual commit, if you're 
trying to track down some issue or other, is really easy. [1]

But the main reason for this reply is to add this idea:

Here, I have my regular user, and I have my admin-hat user.  My regular 
user has sudo locked down quite strictly, with a password required for 
anything not specific parameter locked, etc.  But, the one thing the 
regular usr CAN do, is sudo (with password) to the admin user.  
Additionally, my regular user isn't in the portage, wheel, etc, groups 
either (and polkit is generally locked down for it as well), so it really 
is quite privilege-locked, EXCEPT that it can sudo to admin.

The admin user then has unrestricted passwordless sudo access.  Basically 
root, except that I can type the command unprivileged first, then when 
for instance the rm gives me the expected permissions error, I can see 
that it's what I did indeed intend to rm, and arrow-up, home, sudo in 
front, to actually do it.

The admin user is then what I use to git pull and build the kernel, so 
that's the only user (other than root) with write access to the kernel 
sources.  My normal user doesn't have that access, thus avoiding the 
normal-user-writable security issue mentioned in your (klausman's) blog.  
Since that admin user then has unrestricted passwordless sudo, sudoing 
(from that admin user) to root for the actual install is trivial.


Meanwhile, I actually have a set of kernel maintenance helper scripts 
that I use to update, configure (either oldconfig for the update or just 
to change something...), build and install the kernel.  They're not ready 
for use by the general public yet, but they're a reasonable start, 
including a configuration file for most stuff one might want to change 
(where the kernel dir is located, where the output dir is located so as 
to keep the sources dir itself clean if so desired, whether to auto-
mount /boot for installation, etc).  There's even provision for 
automatically applying patches from a user patches dir! =:^)

Since I've been running a git kernel for several years now, the git-
kernel scripts are current, but I did start on the scripts back when I 
was still using tarballs, so there's scripts that automate most of that, 
as well, tho they're a bit stale now as I've not actually run/tested them 
in a couple years (but I did try to update them for the 3.0 kernel, etc).

If you'd like, I can email them.  As I said, they're not really fit for 
public consumption yet, but it's a reasonable start including a config 
file, and I use it for maintaining my systems (both x86 and amd64, 
separate output dirs based on the bash ARCH variable) here, with a 
maturity and development over several years, so if you're interested in 
/making/ them fit for public consumption, it'd certainly save quite some 
days work over starting from scratch.

Obviously I'm running/testing the scripts as a gentoo user, but other 
than perhaps some of the config file comments, there's not a whole lot 
specific to gentoo about 'em.

---
[1] I routinely run live-git kernels, but don't like to run anything 
before rc1 until some days later, just in case.  So when a release comes 
out, I'll often update a couple days into the new cycle, and then simply 
checkout and build the release tag.  Then sometime after rc1 or rc2, I 
update again, and test from there.  I figure if I need to bisect 
anything, news of any too drastic data-eating bugs pre-rc1 should be 
available, and I can then bisect back into the previously blackout period 
with a bit more confidence.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman