Created attachment 1474 [details] Patch by Colin Watson David Zeuthen: Colin Watson of Ubuntu developed a patch for adding ConsoleKit support to openssh. This is useful because - ConsoleKit is evolving into a utmp/wtmp replacement so tracking users logging in via ssh is useful - We'll do the right thing on the GNOME Shutdown dialog and prompt when trying to shutdown and there are users logged in via ssh - It's the foundation for the PolicyKit authorization framework to grant authorizations to users that only apply when they are logged in from a well-known remote host. E.g. right now I'm working on adding support to PolicyKit for this so you can do things like polkit-auth --user bateman \ --grant org.libvirt.unix.manage \ --constraint remote_host_name:"*.securelab.company.com" (Of course this relies on secure DNS but that's another can of worms)
I'd be very happy if someone from openssh upstream at least commented about the idea and give some hints what to improve on the patch so it would be upstream acceptable. Thank you.
This requires DBus, right? Last time I looked, DBus is GPL. We aren't going to link OpenSSH against any GPL software.
DBus is dual licensed GPL and Academic Free License 2.1 so it should be fine. http://gitweb.freedesktop.org/?p=dbus/dbus.git;a=blob_plain;h=a91ca1d1bbd0bd1a404270daecf606778057b38f;f=COPYING
I don't like this patch, for the following reasons. On the patch itself, it seems like a really bad approach: * We already have a working policy mechanism for OpenSSH in the form of sshd_config Match blocks. Adding another is confusing and potentially dangerous. * Likewise, why duplicate utmp/wtmp? We are going to have to maintain this in perpetuity anyway so why add a parallel mechanism? (to every system process that handles logins!) * Alerting an administrator that there are still logged in users can easily be done by checking utmp/wtmp, so this patch doesn't provide a clear benefit there either. * That a simple registration mechanism requires >250 lines of new code is a sure sign that the API is either horrendously overengineered or insufficiently abstracted. * If something like this is required, wouldn't it make more sense to build it into a small helper program (e.g. something like utempter) so every daemon could use it? (We'd be interested in patches to make sshd use utempter BTW) On dependencies: * I'm not familiar with the AFPL, it looks like a copyleft licence but I can't be certain because it is long, impenetrable legalese. (Why do people insist on creating strange new licenses when we have BSD, Apache and L/GPL?) I'd be much more comfortable if the client libraries that this linked against were unambiguously permissive - I don't want OpenSSH assuming some frankenlicense depending on which --enable- options were selected at configure time. * I'm also worried about libraries that are transitive dependencies. How much will this bloat sshd? (we do care how many shared libraries we link against). * Are any GPL/LGPL libraries in the transitive dependency set? We won't link against GPL and will avoid LGPL that too unless there was some critical reason, i.e. "won't work on a platform without it".
Sorry I didn't reply to this until now. Sending this patch upstream had been on my to-do list and I only happened to notice by chance today that Tomas had helpfully done so for me; apparently I didn't notice I'd been CCed ... The policy mechanism in question is for e.g. GUI administrative tools that want to escalate to root; this allows them to start with much of the GUI greyed out and activated only once an Unlock button is pressed, rather than the whole GUI being run as root or - if it's split such that only a backend process is run as root - failing only when you actually try to apply changes. It's not a policy mechanism for OpenSSH itself, and does not overlap with OpenSSH's Match support in any way as far as I can see. I can't comment on whether utmp/wtmp would have been suitable; I didn't write ConsoleKit or PolicyKit, only this patch (accompanied by a not inconsiderable amount of swearing). On systems that use ConsoleKit and PolicyKit, you can't use GUI administrative tools over SSH's X forwarding without sshd registering with ConsoleKit. This caused us problems with LTSP thin clients. In that sense, this registration is required on our platform; it's not critical in that you can still log in without it, but you definitely lose important functionality without it (not that that's OpenSSH's fault, it's just a matter of keeping up). The D-BUS API is insanely verbose and I'm not exactly its biggest fan. However, I did send a report to the ConsoleKit developers that the separate set_active business really should be replaced by an extra parameter to ck_connector_open_session_with_parameters. I haven't upgraded to a newer upstream version of ConsoleKit yet, so I can't yet say whether that problem has been fixed. If it has, that would cut down the size of the registration code considerably. Separating this out into a separate helper process is tricky because the registering process needs to stay running (D-BUS notices when it goes away and tells ConsoleKit to tear down the session, saving on the need for unregistration code which might fail to get run in the event of a crash), and we need to set an environment variable based on the cookie returned by the registration procedure. This shouldn't be an insurmountable problem, though; I'll have a think about this. I recognise the licensing problem (though I confess I'd overlooked it when I first wrote this patch) and don't have a good answer right now. gnu.org says that the Academic Free Public License is a non-copyleft GPL-incompatible licence, and I guess they'd be likely to say so if it were a copyleft; but I haven't read it enough to determine if it adds any interesting restrictions over and above OpenSSH's licence.
My question is what's missing in OpenSSH and/or PAM so a PAM session module (such as an already existing pam_ck_connector.so) could be used for this purpose?
There's no PAM service that would be suitable for this. You have to wait for the tty and any X display to be set up before you can usefully register with ConsoleKit. With privsep, the PAM session and setcred services are called way too early for this to have happened, and moving them around would take us back to the bad old days and break lots of stuff. I don't see a way to support this with pam-ck-connector short of creating a whole new PAM service just for it, which seems pretty heavyweight. I did try this approach first.
FWIW, http://www.freedesktop.org/wiki/Software/dbus indicates that D-Bus 1.2.0 will be MIT/X11-licensed, as soon as they've managed to track down a couple of straggling licence holders. http://lists.freedesktop.org/archives/dbus/2008-February/009410.html has some more details.
(In reply to comment #8) > FWIW, http://www.freedesktop.org/wiki/Software/dbus indicates that > D-Bus 1.2.0 will be MIT/X11-licensed, as soon as they've managed to > track down a couple of straggling licence holders. > http://lists.freedesktop.org/archives/dbus/2008-February/009410.html > has some more details. Are you sure? That page says "Due to issues putting the re-licensing effort on hold indefinitely, it has been decided to move to 1.2.x versioning scheme" (in the "Download" section).
Oh, drat, yes. Intent more than ability to execute, apparently. I gather that most of the major contributors have agreed, but there are a few who have gone missing ...
I think the easiest approach here actually would be for ConsoleKit to gain a method of session registration which tracks a process ID. Wait, scratch that, Unix sucks - there's no standard way to get notified when a process you're not the parent of exits. Okay, so maybe what we need to do is have a registration method that passes a file descriptor. This would simply be a pipe2(), and openssh sends the read half over DBus (which supports file descriptor passing since 1.4) to ConsoleKit, which accepts it and starts monitoring it. Except, scratch that too because that brings us back to OpenSSH linking against libdbus. So maybe what we need to do is combine these two, and have openssh fork off a child process which sends a file descriptor over, call it openssh-consolekit-helper. Then of course these two processes would have to share a pipe so that openssh-consolekit-helper could get notified when its parent died. On Linux we could just use prctl(PR_SET_PDEATHSIG, 15) though, I personally don't care about non-Linux running ConsoleKit.
(Also, note I am a different Colin =) )