Isolating containers within a single box

This is the kind of post I write to not forget how I did something that was tricky, so don’t expect the best prose out there.

So the hardware I’m hosting the box on is beefy enough to actually be partitioned in multiple containers through LXC — which might not be the best security but it’s still better than nothing, and everybody who has a login there is a trusted person anyway.

I also have a 64-bit prefix from TunnelBroker for IPv6, but I don’t usually have IPv6 at home/work. So what am I using it for? Well, first of all for inter-container exchanges was my idea: the IPv6 are more unique and that makes it easier to write down configuration for them.

But there is another interesting issue to this: I can simply set this up on OpenSSH config with an old trick so that I can jump straight into a container:

User scponly
ControlMaster no
ForwardAgent no
ForwardX11 no

Host *
ProxyCommand ssh -W %h:%p
Compression no

This defines a gateway that uses scponly, then sets up the system to jump around to the other hosts by using their public hostname — which is registered as the AAAA record of its actual IP address.

But… I was hitting some more issues: while I let connections to port 22 (SSH) go through to and from all the containers on IPv6, I wanted to limit the tinderbox instances from connecting to the outside, as that’s important to test software that tries to connect to external hosts during the ebuild phases (I found some more live ebuilds on ~arch — don’t get me started!). I was having some trouble to set it up but at the end this is what works:

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 6573 6035K ACCEPT     all      *      *       ::/0                 ::/0                 state RELATED,ESTABLISHED
   27  5128 ACCEPT     tcp      !br0   *       ::/0                 ::/0                 tcp dpt:22
   34  2408 ACCEPT     icmpv6    *      *       ::/0                 ::/0                
  720 65542 TINDERBOXES  all      *      *       2001:470:d:525:2::/80  ::/0                

Chain TINDERBOXES (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     tcp      *      *       ::/0                 2001:470:d:525::1/128  tcp dpt:3128
   95  9470 ACCEPT     udp      *      *       ::/0                 2001:4860:4860::8888/128  udp dpt:53
   16  1600 ACCEPT     udp      *      *       ::/0                 2001:4860:4860::8844/128  udp dpt:53
    0     0 ACCEPT     tcp      *      *       ::/0                 2001:4860:4860::8888/128  tcp dpt:53
    0     0 ACCEPT     tcp      *      *       ::/0                 2001:4860:4860::8844/128  tcp dpt:53
    2   160 ACCEPT     tcp      *      *       ::/0                 ::/0                 tcp dpt:873
    4   320 ACCEPT     tcp      *      *       ::/0                 2001:470:d:525:1::1/128  tcp dpt:28011

On the FORWARD chain, we first accept all the related/established connections – this is required as otherwise you won’t get the DNS responses back – then we let all connections to port 22 pass through … and critically we let icmpv6 pass.

This is what actually kicked me in the nuts today: first I forgot that ip6tables expects a different identifier for ICMP on IPv6 (as you see, it’s icmpv6 not icmp). Second, when the target hostname is in the same subnet/prefix, it’ll try to use NDP (message type 135, from the logs) to know what the link-local address for it is.

Xfce4, ssh-agent, and smartcards

This is more of a note for myself to not forget this again.

As I said the other day I’m not liking Gnome 3 so much; while the “fallback mode” looks more usable than the shell itself, the fact that to get to the tweaker tool I have to install shell anyway is a bit bothersome. I set up the desktop already, as I said, to use part of Gnome3 stuff, mostly because of a bug in Evolution 2, but now it’s the turn of the laptop, as Gnome 3 has been unmasked

Incidentally, my desktop, and thus my main work environment, is currently unavailable; after the outages of the other day I found out that one of my two UPSes had a fried board, and it couldn’t work without mains running.. given they are doing heavy work on the power line, and the fact that I had to clean up my home office already as new furniture is scheduled to arrive next week, I decided to simply put it away until the new desks are in. Why do the job twice?

At any rate, I decided to go with Xfce4 on the laptop as well, even though this seems to have a slightly different configuration and that spells trouble with Gtk3 for now – in particular fonts are huge, and I don’t know yet why; xdpyinfo reports the correct DPI value for the monitor, and the correct size in millimetres – it still is better than Gnome3. Interestingly enough, the way Xfce4 handles ssh-agent and gpg-agent is quite nice: indeed it actually relies on using gpg-agent with ssh support instead of both of them separately, which is generally compatible with using OpenPGP cards for SSH authentication, but it is a bit incompatible with my suggested script (which I should actually update, at another time, since I modified it a bit since last time).

It is true that I could probably just suggest a few changes to Xfce’s handling code and get it to behave exactly like mine, or at least in a compatible way (the startxfce4 code is very neat, and very hackable!), but for now I wanted to sidestep the issue altogether. I just need for the session script not to override what I set myself. So how do you do that? Simple enough it seems:

% xfconf-query -c xfce4-session -p /startup/ssh-agent/enabled -t bool -s false -n
% xfconf-query -c xfce4-session -p /startup/gpg-agent/enabled -t bool -s false -n

By the way, the reason why I’m not going to spend time trying to fix the compatibility issue between my script and the original code is actually quite simple: the only difference I see is the placement of the agent sockets: my current script uses the standard socket locations (~/.gnupg/S.gpg-agent and ~/.gnupg/S.gpg-agent.ssh), while Xfce4 says nothing and gets the random, temporary locations instead. In the next GnuPG minor version, the default will be changed to use the standard location, so Xfce4 session will be automagically fixed.. that’s about the only reason why I don’t want to spend time on it now.

At least by blogging this I’ll remember how to get back to Xfce4-handled agents, and adapt my script to integrate with that.

New pambase choices

So while I’m still hoping somebody will hire me to finish do a complete audit I’ve at least started working on the new pambase code. To do so I had to make a few more choices than simply maintaining the current status-quo in running state.

First of all, I changed the backend language used to describe the rules. Up to now I abused the C preprocessor with the C macro language; this allows for arithmetic comparison of (properly formatted) version numbers but doesn’t allow for increments and decrements, and it’s not extremely flexible. The new pambase will make use instead of GNU M4 (the same language used by autoconf). M4 is designed to be a macro language by itself, which makes it very simple to implement the kind of copy-and-paste of rules that pambase needs. Not only that but it’s already part of the system set both because of autoconf and because it is one of the standard POSIX utilities.

The second decision to make is a hard one and that is to actually stop proactively support OpenPAM and the FreeBSD operating system. It’s not something I’m doing lighthearted, and I’ll make sure not to force the requirement for Linux-PAM more than it is needed, but right now there is just not enough help to support both implementations. Plus while it made totally sense to support OpenPAM when I first added support for it in Portage (with Linux-PAM series 0.78), with the most recent releases, in particular 1.1 series, Linux-PAM not only doubled up the featureset of OpenPAM, but it also provides a clean interface and very polished code. By focusing more on Linux-PAM (staying, though, as independent as possible from the operating system) it’s quite possible to handle multiple authentication schemes.

Speaking about authentication schemes, when I first implemented Kerberos support in pambase there has been a few problems to be polished with it. For once, chaining a number of authentication schemes is not easy: you cannot use the required option, obviously, because you authenticate usually only against one of the authentication schemes at once; you cannot use optional because otherwise you might login even if all the schemes fail; you cannot use sufficient because that stops the chain at the first authentication that works, and you might have further restrictions in chained services.

The only solution I could find was to move further the solution I applied to Kerberos: using Linux-PAM”s advanced result specification, if any authentication succeed, then instead of proceeding with the rest of method specifications, it jumps directly to the end of the current chain, where a entry will let authentication succeed. if none of the authentication methods succeed, then there is a pam_deny call that ensures that login fails.

Another problem related to multiple authentication schemes is how to handle password changing, which is another problem that we have faced with shadow. Right now we have a lot of configuration files specifying password method chains. A lot of those have likely be added due to misunderstanding that service class as “check against the password” (which is not the case, that’s auth!). For instance, sshd by default provides a password class chain, but OpenSSH does not allow you to change your password in any way.

While cleaning up all the configuration files to ensure that they only list the services they support is something that requires the full audit that I wrote about, at least I will predispose the new pambase to handle that correctly. This means that system-auth will no longer provide password chains; instead a system-password chain will be added that will take care of that and will be used by the very few packages that allow for changing passwords (such as shadow). interestingly enough, the situation here is going to be quite different from what we have now. Many of the alternative authentication methods (PKCS#11, OTP, Yubikey) will not allow to change the authentication password, so they shouldn’t be listed there; some others have different tools to change password, such as Kerberos (kadmin) and pam_ssh, and would most likely not have to be listed there. But for those that have to be listed, including Gnome-Keyring, changing password should act on all of them, not just one, so the skip system described above cannot apply there.

Unfortunately, not only this require quite some changes on the pambase package, but it has to be coordinated with a number of other packages, such as shadow, sshd and so on. Given this, don’t expect it until mid-to-end of November. Probably later if I find some other job to follow. Once again, if somebody is interested in having better PAM support in Gentoo, it can be done faster, but not in my spare time. It’s not something a single volunteer can deal with in spare time.

Random Gentoo fixes

In the past week or so, I’ve been working in parallel on two Gentoo-related project; one is that I wrote about, for which I need to bypass NATs and allow external IPv6 access while the other will probably be more known in the next few days, when I deploy in Gentoo the code I’m developing.

Both works are something I’m paying to do, even though for the former I’m paid not nearly enough I should, and interestingly, both seem to require me to make some seemingly random, but to my aim quite important changes to Gentoo. Since they are unlikely to show up on anybody’s radar as they are, but some might be of interest to other people doing similar things, I thought I could give you a couple of heads’ up on these:

  • first of all, speaking about Quagga I changed the init scripts to make use of logger if available; this should depend on the configuration files (you can decide whether to use syslog or not) but since that only works with OpenRC and I’m not sure how to test for OpenRC within an init script, I decided to simply add a use requirement on all of them; as it is, it won’t require the logger, but if it’s in the runlevel, it’ll run after it;
  • again on topic of init script, I tweaked the OpenSSH sshd init script so that it doesn’t forcefully regenerate the RSA1 host key, as that’s only used by the version 1 of the SSH protocol, which is not enabled by default; if you do enable it, then RSA1 host key is regenerated, but it’s no longer happening if you don’t request it in sshd_config; I wanted to make it possible to disable RSA/DSA keys for SSH2 but it’s unclear how that would work; this reduces the amount of time needed to start up a one-off instance of Gentoo, such as a SysRescueCD live, or EC2, and reduces the entropy consumption at boot time;
  • tying it up, I’ve tried running audio-entropyd on the two boxes I have to deploy, hoping that it would make it possible for me to replenish the entropy without having to buy two more EntropyKeys (which would erode my already narrow profit margin); unfortunately it didn’t work at all, turning up a number of I/O errors, but the good news is that the timer_entropyd software – that Pavel is proxy-maintaining through me – works pretty nicely for this usage, and I’ve now opened a stable request for it;
  • also while trying to debug audio-entropyd, I’ve noted that strace didn’t really help when calls to ioctl() are made with ALSA-related operations; the problem is that by default, the upstream package is sent down with a prebuilt list of ioctl definitions; I’ve found a way to remove this limitation, which is now in tree as 4.5.20-r1, although I did break build with Estonian language — because the upstream code is not compatible in the first place; I’ll be fixing the Estonian problem tomorrow as soon as I have time;
  • I have started looking into the pwgen init script that is used by our live CDs and by SysRescueCD; again, there are a few useful things with that approach, but I really want to look more into it because I think there is room for improvement;
  • tomorrow and in the next days, depending on how much time I’m left with, I’ll be starting to try again the PKCS#11 authentication — last time I ended up with a system that let me in as root with any password, now I think how I can solve it, but it’ll require me to rewrite pambase almost from scratch;
  • not really related to my work project but I helped a bit our Hardened team to fix a suhosin bug and sent the patch upstream; I’ll be writing in deeper details about this – again as I find time – since it actually motivates me to resume my work on Ruby-ELF to solve the problem at the root.

On a different note, I switched my router from using pdnsd to unbound; while documentation leaves a lot to be desired, unbound seems to perform much better, and also does work with both IPv4 and IPv6 socket listening, which doesn’t seem to be the case at all for pdnsd. I also taken down some notes about using the bind ddns protocol since the documentation “robbat2’: pointed me at is probably out of date now.

Smart Cards and Secret Agents

Update, 2016-11: The following information is fairly out of date, six years later, as now GnuPG uses stable socket names, which is good. Please see this newer post which includes some information on setting up agent forwarding.

I’ve been meaning to write about my adventure to properly set up authentication using the Fellowship of FSFe smartcard for quite a while, and since Markos actually brought the subject up earlier tonight I guess today is the right time. Incidentally, earlier in my “morning” I had to fight with getting it working correctly on Yamato so it might be useful after all…

First of all, what is the card and what is needed to use it… the FSFe Fellowship card is a smartcard with the OpenPGP application on it; smartcards can have different applications installed, quite a few are designed to support PKCS#11 and PKCS#15, but those are used by the S/MIME signature and encryption framework; the OpenPGP application instead is designed to work with GnuPG. When I went to FOSDEM, I set up my new key using the card itself.

The card provides three keys: a signing key, an encryption key, and an authentication key; the first two are used for GnuPG, as usual; the third instead is something that you usually don’t handle with GnuPG… SSH authentication. The gpg-agent program can actually handle your standard RSA/DSA keys for SSH, but that’s generally not very useful; if combined with the OpenPGP smartcard, this comes very useful.

So first of all you need a compatible smartcard reader; thankfully the CCID protocol is pretty standard and should work fine; I’ve got luck and three out of three smartcard readers I have work fine; one is from an Italian brand (but most likely built in Taiwan or China), the other is a GemAlto PinPad, and the third is the one integrated in my Dell laptop, Broadcom BCM5880v3. The last one requires an updated firmware and a ccid package capable of recognizing it… the one in Gentoo ~arch is already patched so that it works out of the box. I got mine at Cryptoshop which seems a decent place to get them in Europe.

Out of experience, at least GnuPG seems to have problems dealing with pinpads, and quite a few pinpad-provided readers seem to have driver problems; so get a cheaper, but just as valid, non-pinpad reader.

On the software side, there isn’t much to need: GnuPG itself could use the CCID readers directly, but my best luck has been using pcsc-lite; just make sure your pcsc-lite does not use HAL but rather has libusb support directly, by setting -hal usb as USE flags for it. GnuPG has to be built with the smartcard USE flag; pcsc-lite USE flag will give you the dependency as well, but it does not change the build at all. Update: Matija noted that there is also the need to install app-crypt/ccid (which is the userspace driver of the CCID-based smartcard readers); for whatever reason I assumed it was already a dependency of the whole set but that is not the case.

Make sure the pcscd service is started with the system, you’re gonna need it.

To actually make use of the key properly you’re going to need to replace ssh-agent with gnupg-agent…. more interesting, GNOME-Keyring also replaces ssh-agent, but if you let it do so, it won’t handler your OpenPGP card auth key! So you’re going to override that. Since using keyring with this setup seem to be impossible, my solution is to use a simple wrapper which I now release under CC-BY license.

You got run this script on every shell and your X session as well, for this to work as intended (it is needed in X session so that it works with libvirt over SSH otherwise virt-manager will still try to get the key from gnome-keyring). To do so I added a source of that script from both my ~/.shrc file and my ~/.xsession file, and make sure the latter is called; to do so I have this:

# in both ~/.shrc and ~/.xsession:
. /path/to/gpg-agent-wrapper

# in /etc/X11/xinit/xinitrc.d/01-xsession
[ -f ${HOME}/.xsession ] && . ${HOME}/.xsession

The trick of the script is making sure that gpg-agent is not already running, that it does not collide with the current information, but also it takes care of overriding gnome-keyring (it could be also done by changing the priority of ~/.xsession to be higher than gnome-keyring), and ensures that the SSH Agent Forwarding works… and yes it works even if on the client there is gpg-agent used for SSH, which means it can forward the card’s authentication credentials over a network connection.

So here it is, should be easy enough to set up for anybody interested.

Ranting on: libvirt remote

*This is a rant. This is not meant to be constructive, so it is not. If Rich is reading this, he might find some points he can work on; if I had the time, I would be working on them myself; if you feel like you agree with my rant and would like to get the stuff implemented, you can hire me to work on this. But for the rest, this is a rant, so if you’re not in the mood to read my rants, you might want to skip over this.*

The laptop from hell is finally shaping up; the smartcard reader works, after editing the ccid files (yes I have to publish the patches up there). Thanks to this I finally wanted to take one further step to make use of it to augment my productivity. One of these things, which I couldn’t feasibly do with OS X, is handling my virtual machines park via virt-manager.

Now, libvirt is designed to be a client-server system, and the server might not be local. There are three transport options to use remote servers: clear-text, TLS, and SSH tunnelling. Now, the clear-text is an obvious bad choice; SSH would be a good choice, if it wasn’t that.. it only works with the root user. There is no way to configure which user to use for the ssh tunnel, and I really don’t want to enable SSH root logins.

TLS is an interesting choice. With this transport, the authentication on the server side is done similarly to what OpenVPN does: you have a personal certification authority (CA), one key/certificate pair for the server, and then one pair per client. All the certificates are signed by the CA itself, and that validates the client to connect to the server. It’s a very nice approach for hosting providers I guess, since you can have a number of workstations that have the certificates set up properly to connect to the farm of virtualisation servers. Unfortunately it has design flawswhen you want to use it with something like a laptop.

First of all, while the server’s certificates and key files’ paths are configurable in the libvirtd.conf file, the client’s files are not configurable, they are hardcoded at build-time based on the system configuration directory (for Gentoo, that’s /etc). They are also only used host-global, as it does not even check for an override in the user’s directory. And this is a double-problem because the certificate has to be passwordless! Or, to put it in a different way, it has to be insecure, lacking a password protection. And since I just said that it does not allow for per-user overrides, you cannot even rely purely on encrypting your home directory. Alternative option is to symlink them from the /etc paths to your home directory but that’s not elegant at all.

It gets even a little worse: to access the display of the virtual machines libvirt tries to do a smart thing, by using the VNC protocol rather than reinventing the wheel. Now, a lot of comments can be written regarding the choice of using the VNC protocol itself, but the fact that it doesn’t reinvent a new one is positive. Unfortunately, when accessing a remote server via TLS, instead of muxing the VNC protocol over the same connection, it simply tries to connect to the VNC display on the remote host. And of course it’s a separate configuration to tell qemu to open the VNC on the correct host. D’oh!

Okay so I get to configure qemu to open the VNC on all interfaces, all IPs… but here’s the catch: for TLS to work correctly, you need to provide correct hostnames, stable hostnames; to do so I decided to use IPv6, since my boxes’ IPv6 are already forward-confirmed, thanks to the latest Hurricane Electric service (providing name server hosting without asking me to maintain my own). Unfortunately, it seems just like qemu does not support IPv6 at all, which means that .. the connection will not work because the hostname will find no hit.

It really doesn’t look too difficult to implement at least part of these features, like choosing the certificate files path, or connecting as a different SSH user. Sure, if you were to shoot high, you could probably consider using a single SCTP socket with multiple channels to multiplex the libvirt protocol together with the VNC connections, but that’s not needed at all. It really just need a few touches here and there to make it much more usable.

Even little differences count

If you ever find yourself relying for any reason on the behaviour of Microsoft Excel, make sure you never ever change its version. Seems like I had some problems with my job because the version of Microsoft Excel I bought is not the same as the one they are using at the office.

Also, if you want to shut up Valgrind’s warnings to make life easier for people developing against a given library, it’s time you hear about suppression files, rather than trying to change code you don’t know enough about.

Seems like a little difference in the patches applied by Debian (and Ubuntu) made OpenSSL vulnerable like it never was. Even my keys has to be considered compromised, so I had to change them on every service I use. This means Alioth, Gentoo’s Infra, GentooExperimental, SourceForge, Berlios, Savannah, Rubyforge, Launchpad (don’t ask), KDE, and of course my own server.

I think yesterday will be remembered for the years to come as a critical day. It’s like a city of the size of Milan starting to change the door locks for all the apartments at once. I’m surprised there hasn’t been more confusion.

Myself, I’m starting to consider some other kind of authentication, as the passphrases I use for the keys are quite long, and I’m tired of having to key it in every time I start the system. SmartCard and authentication tokens start to look quite nice, and it would be a nice test for Gentoo’s PAM infrastructure.

It’s unfortunate that Alon, who as far as I remembered managed these things, left Gentoo yesterday :/ Although I suppose that if I am to start looking into these things I might be able to lend a hand.

At the moment, I’m oriented toward an authentication token, as that would make it possible for me to have it around on the laptop too at any time. Strangely enough, I found an Italian producer, Eutronsec, and their CryptoIdentity token seems to be supported by pcsclite.

SmartCards are more likely useful in an organisation where you’d have one reader on a given system and many many cards around. Here I’d just have one reader and one smartcard if I did go that way. If the Italian ID card was a SmartCard I could have chosen that, but at the moment it doesn’t look like a convenient idea.

Unfortunately it seems like Eutronsec only sells to other companies, I’ve mailed them asking if they could sell to single entities, but I haven’t received an answer yet. I’m afraid I’ll have to start looking for alternatives if I want to proceed on this road.

On a totally different topic, but still related to “little differences”, I’m having difficulties finding cups that I can use with my espresso machine. Usual teacups that my family uses for coffee (yeah they are quite larger for coffee, we’re used to those though, a six servings Moka is good for three here) tend to be too thin at the bottom and large at the top, so the coffee spills a lot, especially when doing a hot boiling espresso. Mugs are quite better for the task, but all the ones I have here are little less than 9.5 centimetres (little more than three and a half inches), and require to be skewed to enter the espresso machine.

The idea would be an 8.5cm cup, but I can’t seem to find them in the shops around here, they are either 6 centimetres, which is way too short, or they are the “usual” mug size. In a Chinese shop around here I found some nice cups that are about 12cm actually, I was tempted to take one to hold the milk for cappuccino, actually, but they are quite too high for the espresso machine.

The mess I found with PAM

So I started working, as I anticipated before, toward centralising a bit of PAM configuration for Gentoo in a pambase package. It’s still in flux a bit, but the base should be here already.

The 20080219.1 ebuild now install system-local-login and system-remote-login. ConsoleKit and similar should go to system-local-login, while system-remote-login is reserved to ssh and similar software.

I opened a tracker bug for the new pambase system, I’ve started the cleanup process for pam_passwdqc (which will be available as alternative to cracklib in the pambase ebuild soon, so that it also allows a FreeBSD-like default – FreeBSD uses pam_passwdqc by default), and I started converting ebuilds.

The new setup is quite flexible, I think, but it’s not really complete yet. Unfortunately I’m dedicating just part of my daily time on this, as I’m also working on C# (and swearing against Microsoft for their broken documentation about clipboard usage!). I’m still uncertain on a couple of points, but it should come out nicely in the end.

I’m also wondering if I should move ftpd support from ftpbase into pambase, it makes sense to me as that way it is handled properly by all current and future PAM implementations supported by Gentoo. ftpbase is currently maintainer-needed, so it makes even more sense to bring at least part of it under a team, even if understaffed as PAM team is.

I’ll also have to talk with the net-mail team about mailbase for similar reasons.

Unfortunately, doing this is also showing off big problems on how PAM was handled up to now. There are packages with a pam USE flag, but not installing any pam.d configuration file, there are packages that install upstream-provided files that are not valid in Gentoo, there are packages still providing configuration files referring to pam_stack (in comments). I’m starting to wonder if I should ask the Portage (and QA) team to add an extra QA check for PAM configuration files after build, so that I can find more easily packages breaking the rules.

I admit it’s not easy on the maintainers’ part as I haven’t finished writing the PAM documentation. I hope to be free from work in the next weeks, but I start to wonder if I’ll ever be. And I also hate working on PAM as always, but somebody has to do that, no?

Anyway, two packages are plainly broken and not looking up to be fixed: net-misc/ssh (which should be punted from the tree ASAP, thanks Gustavo!) and net-misc/lsh (another SSH implementation, it has completely broken PAM – it checks against other, which is set to deny any user – and no maintainer; if you want to save it, step up, and I might actually fix the PAM part).

All your pambase are belong to us

And with this I finally given up on this omnipresent meme. But I couldn’t find a better title to present to the world my new PAM infrastructure package: sys-auth/pambase.

As I suggested yesterday I wanted to improve the way that the basic PAM configuration is handled in Gentoo to make it simpler to add caps support. Last night I decided to start working on it, and it was a quite easy target actually.

The new sys-auth/pambase package installs the basic PAM configuration files for all implementations. This means that the same basic file configuration used by Gentoo Linux is shared with Gentoo FreeBSD, and changing one will also change the other. No more duplication of the files in sys-freebsd/freebsd-pam-modules and sys-libs/pam.

Of course different implementations (Linux-PAM and OpenPAM, FreeBSD modules and NetBSD modules) implement different modules and different parameters. So instead of having the final file in the pambase package, it contains some pre-parsing files, that cpp (yes, the C Pre Processor proper) expands to the final file. Through a few directives, I can then enable or disable feature on a per-implementation basis.

In addition to the system-auth PAM configuration file (that is referred to by almost all other services to provide system-integrated configuration), pambase installs a system-login PAM configuration file. What is the difference? This configuration file should be used for services like login (from shadow), xdm, gdm, kdm, entrance, … I suppose that any of you who ever tried to get stuff like ConsoleKit working would be able to grasp what is so interesting in this.

A single consolekit USE flag on pambase could allow to switch on and off ConsoleKit authentication on all major console logins without user intervention (beside enabling the USE flag and running etc-update).

For now this is a testing framework, as I’m considering if I should have system-login plus system-console-login, so that sshd for instance can use system-login (to enable stuff like motd, userfiles and similar), but still not use ConsoleKit and similar, and it still has to be tested on Gentoo FreeBSD.

I hope to coordinate with GNOME and KDE teams later today to have gdm and kdm to use the new capability, still without any keyword, and be able to put this in production in a few months, also replacing virtual/pam step by step (as it does take care of properly depending on the right PAM implementation with its eventual modules).

One nice thing is that it will probably have a huge lot of USE flags, as it would then allow to just specify a flag (say, caps) to enable the correspondent PAM module into the main system configuration, depending on the right ebuild. While most complex configurations wouldn’t work well that way, basic stuff is likely going to make it easier to manage system login for users.

Anyway, as you’ll guess this will be my project in the next few weeks (I’ll also return on linking problems, but it’s better for my sanity if I change topic from time to time for a while).