The
Linux kernel keyring is effectively a mechanism to allow shoving blobs of data into the kernel and then setting access controls on them. It's convenient for a couple of reasons: the first is that these blobs are available to the kernel itself (so it can use them for things like NFSv4 authentication or module signing keys), and the second is that once they're locked down there's no way for even root to modify them.
But there's a corner case that can be somewhat confusing here, and it's one that I managed to crash into multiple times when I was implementing some code that works with this. Keys can be "possessed" by a process, and have permissions that are granted to the possessor orthogonally to any permissions granted to the user or group that owns the key. This is important because it allows for the creation of keyrings that are only visible to specific processes - if my userspace keyring manager is using the kernel keyring as a backing store for decrypted material, I don't want any arbitrary process running as me to be able to obtain those keys[1]. As described in keyrings(7), keyrings exist at the session, process and thread levels of granularity.
This is absolutely fine in the normal case, but gets confusing when you start using sudo. sudo by default doesn't create a new login session - when you're working with sudo, you're still working with key posession that's tied to the original user. This makes sense when you consider that you often want applications you run with sudo to have access to the keys that you own, but it becomes a pain when you're trying to work with keys that need to be accessible to a user no matter whether that user owns the login session or not.
I spent a while talking to David Howells about this and he explained the easiest way to handle this. If you do something like the following:
$ sudo keyctl add user testkey testdata @ua new key will be created and added to UID 0's user keyring (indicated by @u). This is possible because the keyring defaults to 0x3f3f0000 permissions, giving both the possessor
and the user read/write access to the keyring. But if you then try to do something like:
$ sudo keyctl setperm 678913344 0x3f3f0000where 678913344 is the ID of the key we created in the previous command, you'll get permission denied. This is because the default permissions on a key are 0x3f010000, meaning that the possessor has permission to do anything to the key but the user only has permission to view its attributes. The cause of this confusion is that although we have permission to write to UID 0's keyring (because the permissions are 0x3f3f0000), we don't
possess it - the only permissions we have for this key are the user ones, and the default state for user permissions on new keys only gives us permission to view the attributes, not change them.
But! There's a way around this. If we instead do:
$ sudo keyctl add user testkey testdata @sthen the key is added to the current session keyring (@s). Because the session keyring belongs to us, we possess any keys within it and so we have permission to modify the permissions further. We can then do:
$ sudo keyctl setperm 678913344 0x3f3f0000and it works. Hurrah! Except that if we log in as root, we'll be part of another session and won't be able to see that key. Boo. So, after setting the permissions, we should:
$ sudo keyctl link 678913344 @uwhich ties it to UID 0's user keyring. Someone who logs in as root will then be able to see the key, as will any processes running as root via sudo. But we probably also want to remove it from the unprivileged user's session keyring, because that's readable/writable by the unprivileged user - they'd be able to revoke the key from underneath us!
$ sudo keyctl unlink 678913344 @swill achieve this, and now the key is configured appropriately - UID 0 can read, modify and delete the key, other users can't.
This is part of our ongoing work at
CoreOS to make
rkt more secure. Moving the signing keys into the kernel is the first step towards rkt no longer having to trust the local writable filesystem[2]. Once keys have been enrolled the keyring can be locked down - rkt will then refuse to run any images unless they're signed with one of these keys, and even root will be unable to alter them.
[1] (obviously it should also be impossible to ptrace() my userspace keyring manager)
[2] Part of our Secure Boot work has been the integration of
dm-verity into CoreOS. Once deployed this will mean that the /usr partition is cryptographically verified by the kernel at runtime, making it impossible for anybody to modify it underneath the kernel. / remains writable in order to permit local configuration and to act as a data store, and right now rkt stores its trusted keys there.
comments
Hi, Craige.
We've been hard working with the Gnocchi team these last months to store your
metrics, and I guess it's time to show off a bit.
So far Gnocchi offers scalable metric storage and resource indexation,
especially for OpenStack cloud but not only, we're generic. It's cool to
store metrics, but it can be even better to have a way to visualize them!
Prototyping
We very soon started to build a little HTML interface. Being REST-friendly
guys, we enabled it on the same endpoints that were being used to retrieve
information and measures about metric, sending back 
Over the last weekends I finally managed to finish 
during the last weeks, I spent time mostly with 
The first updated in the 0.12.* series of 
Another improvement would be to change the font from the canonical
Helvetica to something prettier, like suggested in 
Over the past few years, a plethora of 
I knew it was about this time of the year 10 years ago when my Debian account
was created, but I couldn't remember the exact date until I looked it up
earlier this evening: today :). Rene Engelhard had been my advocate, and Marc
Brockschmidt my AM. Thanks guys!
A lot of time has passed since then, and I've worked in various parts of the
project. I became an application manager almost immediately, and quickly got
into the NM front desk as well, revamping parts of the NM process which had
become pretty bureaucratic (I think we are now, 10 years later, back where we
should be, thanks to almost all of the paperwork being automated, thanks
Enrico!). I've processed 37 NMs, most of them between 2005 and 2008, later I
was only active as front desk and eventually Debian account manager. I've
recently picked up AMing again, which I still find quite refreshing as the AM
will always also learn new things.
Quality Assurance was and is the other big field. Starting by doing QA uploads
of orphaned packages, I attended some QA meetings around Germany, and picked up
maintenance of the DDPO pages, which I still maintain. The link between QA and
NM is the MIA team where I was active for some years until they kindly kicked
me out because I was MIA there myself. I'm glad they are still using some of
the scripts I was writing to automate some things.
My favorite MUA is mutt, of which I became co-maintainer in 2007, and later
maintainer. I'm still listed in the uploaders field, but admittedly I haven't
really done anything there lately.
Also in 2007 I started working at credativ, after having been a research
assistant at the university, which meant making my Debian work professional. Of
course it also meant more real work and less time for the hobby part, but I was
still very active around that time. Later in 2010 I was marrying, and we got
two kids, at which point family was of course much more important, so my Debian
involvement dropped to a minimum. (Mostly lurking on IRC ;)
Being a PostgreSQL consultant at work, it was natural to start looking into the
packaging, so I started submitting patches to postgresql-common in 2011, and
became a co-maintainer in 2012. Since then, I've mostly been working on
PostgreSQL-related packages, of which far too many have my (co-)maintainer
stamp on them. To link the Debian and PostgreSQL worlds together, we started an
external repository (apt.postgresql.org) that contains packages for the
PostgreSQL major releases that Debian doesn't ship. Most of my open source time
at the moment is spent on getting all PostgreSQL packages in shape for Debian
and this repository.
According to minechangelogs, currently 844 changelog entries in Debian mention
my name, or were authored by me. Scrolling back yields memories of packages
that are long gone again from unstable, or I passed on to other maintainers.
There are way too many people in Debian that I enjoy(ed) working with to list
them here, and many of them are my friends. Debian is really the extended
family on the internet. My last DebConf before this year had been in Mar del
Plata - I had met some people at other conferences like FOSDEM, but meeting
(almost) everyone again in Heidelberg was very nice. I even remembered all
basic Mao rules :D.
So, thanks to everyone out there for making Debian such a wonderful place to
be!
The C1 Server
Debian LTS
August was the fourth month I contributed to 
So I decided to rename all the local folders to the scheme described in the above guide. At the end I want to have a folder layout as follows:
My monthly report covers a large part of what I have been doing in the free software world. I write it for 
For the concrete work I did during DebConf, I can only claim two schroot uploads to fix the lack of support of the new overlay filesystem that replaces aufs in the official Debian kernel, and some Distro Tracker work (fixing an issue that some people had when they were logged in via Debian s SSO).
While the numerous discussions I had during DebConf can t be qualified as work , they certainly contribute to build up work plans for the future:
As a Kali developer, I attended multiple sessions related to derivatives (notably the 