09:51 < ogra_cmpc_> lool, you had a consolekit hack for for startx in mobile, right ? how evil is that change ? its really mean to disable all users that use startx from doing administrative desktop tasks imho so if it doesnt rip huge security holes that would probably be a nice addition...
09:52 < ogra_cmpc_> pitti, cr3 had promised me the new gui would be done for hardy (doesnt seem to be the case though :( )
09:52 < lool> ogra_cmpc_: We're working on it, but it isn't working for now
09:53 < ogra_cmpc_> ah, k, i thought you had it solved already
09:53 < lool> ogra_cmpc_: What we managed doing is starting a CK session; there are many ways to do this
09:53 < lool> The problem we're facing at the moment is making that session the active one
09:53 < ogra_cmpc_> yeah, i have a similar prob with ltsp logins
09:53 < pitti> seb128: sorry if that causes some more FTBFS spam
09:53 < lool> It would seem that using a root-only CK call to start the session with the relevant params might help it, but we didn't solve this yet
09:54 < lool> ogra_cmpc_: Finally, we have a stop gap workaround ATM which is to use a root running daemon to fix the CK session
09:54 < cjwatson> lool: I have code that marks the session active by hand, if it would help
09:54 < lool> cjwatson: Does it require root?
09:54 < ogra_cmpc_> well, in any case it would be nice to have it un the general distro package so we can make use of it everywhere if its not to hackishj
09:54 < lool> cjwatson: Anyway, any contribution at this point is useful
09:54  * lool grabs bug id
09:55 < lool> https://bugs.edge.launchpad.net/ubuntu/+source/xinit/+bug/199486
09:55 < lool> ogra_cmpc_, cjwatson ^^^
09:55 < lool> pitti: You're also welcome to comment
09:55 < cjwatson> lool: not certain
09:55 < lool> I discussed this with mccann and he told us to use ck-start-session or something, which is only available in newer consolekit
09:56 < ogra_cmpc_> is that like the pam thing wrapped ?
09:56 < lool> However it's not helping as it's not aware of the DISPLAY at the moment it's launching the session
09:56 < lool> ogra_cmpc_: Exactly, so doesn't solve the issue we're having
09:56 < ogra_cmpc_> yeah
09:56 < lool> I didn't have time to resume discussion
09:56 < cjwatson> you probably don't want to use the pam module as such
09:56 < ogra_cmpc_> right
09:56 < lool> cjwatson: Oh why not?  We planned doing so
09:57 < cjwatson> why doesn't xinit have root privileges?
09:57 < cjwatson> oh, if you're willing to hack complete PAM support into xinit, sure
09:57 < lool> cjwatson: It wasn't enough, but I think it did as well as ck-start-sesison
09:57 < cjwatson> I didn't think it started a PAM session at the moment, though
09:57 < lool> cjwatson: We're using "su" before starting startx
09:57 < cjwatson> starting a PAM session requires root at *some* point
09:57 < pitti> lool: if ck-launch-session helps you, we can certainly port it
09:57 < lool> pitti: I think not
09:57 < pitti> lool: sounds just like a shallow wrapper around open_session_with_parameters()?
09:57 < lool> pitti: Michael checked the code and it basically does what the xinit patch did
09:58 < ogra_cmpc_> pitti, it does the same as the already existing pam module
09:58 < pitti> ah, ok
09:58 < lool> pitti: Unfortunately that call is root-only
09:58 < pitti> so the problem is not that you need a CLI tool instead of a lib call, but the place where to do it
09:58 < lool> pitti: So we'd have to move to the Xorg server *shiver*
09:58 < lool> pitti: Exactly
09:58 < pitti> lool: right, it must be root only
09:58 < lool> pitti: I'm just mentionning this because upstream told us so, but I think it was misguiding
09:58 < cjwatson> lool: I've attached the openssh patch to the bug, but I'm not sure how much it'll help you
09:58 < lool> cjwatson: Thanks
09:59 < cjwatson> lool: why is starting the CK session as root not an option? As you say, you do have root at some point in the process
09:59 < lool> cjwatson: Because we don't have the display at that time
10:00 < lool> cjwatson: It's basically su launching startx as ume which spawns Xorg as root
10:00 < lool> (I mean Xorg is suid root)
10:00 < cjwatson> oh, right
10:00 < lool> cjwatson: Thanks for the patch
10:01 < cjwatson> doing it in the X server would be too evil for words
10:01 < lool> cjwatson: What's the reason for merging it into ssh instead of pushing for the PAM module?  Is this for non-PAM sshd uses?
10:01 < lool> cjwatson: haha
10:01 < cjwatson> you can't use the PAM module with openssh for reasons too tedious to enumerate
10:01 < cjwatson> basically privilege separation awkwardness
10:01 < lool> Is this a design issue of the CK PAM module?
10:01 < cjwatson> no
10:02 < lool> As in, it should be using some helper to gain the privs it needs
10:02 < lool> AH
10:02 < cjwatson> no, it's just how openssh internals are arranged
10:02 < cjwatson> actually sort of similar to your problem in some ways - when the PAM session is opened, you don't know DISPLAY yet
10:02 < lool> It's sad to have PAM and to not be able touse it
10:02 < cjwatson> because the client hasn't yet requested the forwarded X connection
10:02 < lool> Oh
10:02 < lool> Ok
10:03 < cjwatson> or, for that matter, the tty
10:03 < cjwatson> you can have ttyless ssh sessions, you see ...
10:03 < lool> Sure
10:03 < lool> I understand the tty can be requested at any time, just like you can add port forwarding or X11 forwarding
10:03 < lool> And it's way too late to hope to use sshd root rights or PAM
10:04 < cjwatson> openssh actually does have a method to get back to root
10:04 < lool> cjwatson: Thanks for the explanations
10:04 < cjwatson> which in fact is used by the consolekit patch
10:04 < ogra_cmpc_> you could probably ssh -X localhost and have a sshd listen on lo
10:04 < cjwatson> but I don't think that's relevant to your problem
10:04 < lool> cjwatson: Oh; I wouldn't have expected that
10:04 < cjwatson> it's very carefully constrained
10:04 < lool> cjwatson: It's not relevant, but interesting nevertheless :)
10:04 < ogra_cmpc_> i.e. bring up your X server and loop back to run xinint though ssh
10:04 < cjwatson> if you see a mention of the "monitor" in openssh source, that's what that's doing
10:05 < cjwatson> lool: I sort of feel that, instead of running the whole of startx under su, the su ought to be deeper
10:05  * lool slaps ogra_cmpc_ 
10:05 < ogra_cmpc_> heh
10:05 < lool> ;)
10:05 < cjwatson> so that you can pass some bits of information back up to something running as root that can open the CK session for you
10:06 < cjwatson> of course there is a certain historical expectation that running startx as a mortal user will DTRT
10:06 < lool> Yes
10:06 < ogra_cmpc_> ++
10:06 < lool> I've used it for years when I considered gdm dangerous for my X sessions
10:06 < ogra_cmpc_> gdm is fine as long as you dont want to restart or stop it :)
10:07 < lool> Also, I guess it's going to make us start a Xsession as root too
10:07 < cjwatson> exactly which dbus call is root-only?
10:07 < lool> cjwatson: The one with params
10:07 < lool> cjwatson: Which are required to pass the x11-display
10:07 < lool> cjwatson: The FD bug has some details of the params which we might want to set
10:07 < cjwatson> because I thought I remembered testing this as an ordinary user
10:08 < lool> Michael Frey told me it wouldn't work as it was root only I think
10:08 < lool> He commented as such in the FD bug
10:09 < cjwatson> ah, yes, you're right
10:09  * ogra_cmpc_ thinks it was to early for CK inclusion
10:09 < lool> Now, I wonder whether it would make sense to let Xorg report to CK when a display is spawned and a VT allocated
10:09 < cjwatson> I guess I must have been using sudo dbus-send
10:09 < cjwatson> this really doesn't feel right in the X server at all
10:09 < lool> I understand we don't want to start a CK session there, but as Xorg is setting the VT etc.
10:10 < lool> cjwatson: But Xorg is the exact place where the system objects are requested/created
10:10 < lool> And where the DISPLAY comes to life
10:10 < lool> Naturally, I'm not happy with DBus coming into play with Xorg  :-/
10:10 < pitti> to me it feels slightly ugly to make X.org depend on CK
10:10 < pitti> (for a library call)
10:11 < pitti> it's less ugly to try and call ck-create-session, and just ignore if it isn't there
10:11 < lool> What about a Xorg module?
10:11 < cjwatson> the X server is wrong because if you're using remote X then it is on the wrong machine
10:11 < cjwatson> the CK session is a client-side concept, not server-side
10:12 < cjwatson> (with the usual confused X meanings of client and server)
10:12 < lool> cjwatson: I see; so we can have multiple sessions with the same display?
10:12 < cjwatson> consider X sessions forwarded over ssh
10:12 < cjwatson> they share an X server, but the actual DISPLAY variable is something different on a different host
10:12 < cjwatson> same goes for xdmcp
10:13 < cjwatson> this is why it should be the responsibility of the session manager
10:13 < cjwatson> or the display manager if relevant
10:13 < lool> Yes, but then apps launched in the remote SSH session are going to which CK session?  One spawned by sshd and related to the virtual DISPLAY, no?
10:13 < cjwatson> maybe you just need a trivial display manager
10:13 < lool> Or is this extending the local CK session?
10:14 < cjwatson> right, in the case of ssh the CK session is started by sshd, because sshd is effectively acting as a trivial display manager
10:14 < cjwatson> and session manager, rolled into one
10:14 < lool> cjwatson: So sshd is where the virtual DISPLAY comes to birth
10:15 < cjwatson> sort of, but I think that's the wrong way to think about it
10:15 < ogra_cmpc_> its a proxy server
10:15 < cjwatson> display managers are actually quite easy to write
10:15 < cjwatson> if you aren't trying to be gdm
10:16 < cjwatson> LTSP has a trivial one called ldm, and I wrote adapted versions of that for oem-config and ubiquity
10:16 < lool> cjwatson: Do we have anything close to such a dumb DM?
10:16 < lool> Ah LDM, thanks
10:16 < cjwatson> it's 100-odd lines of Python
10:16 < ogra_cmpc_> well, ldm is C now
10:16 < cjwatson> right, oem-config-dm isn't though ;-)
10:16 < ogra_cmpc_> look at the pre gutsy code for ldm in python
10:16 < lool> cjwatson, ogra_cmpc_, pitti: mind if I copy this log to the bug report?
10:16 < cjwatson> oem-config-dm is probably a better place to start as it doesn't have the ssh stuff
10:16 < cjwatson> not at all
10:17 < pitti> of course not
10:17 < ogra_cmpc_> fine with me
10:17 < pitti> it's publically logged anyway
10:17 < lool> pitti: (Yeah, but I asked for politeness ;)
10:17 < cjwatson> in oem-config-dm's case, it is told the display by its caller
10:18 < cjwatson> but the same usually goes for xinit as called by startx, doesn't it?
10:18 < lool> Yes
10:18 < ogra_cmpc_> yep
10:18 < cjwatson> I guess providing a display to startx isn't mandatory
10:18 < lool> I think the act of creating the CK session in xinit makes sense; we just have to figure a way for it do provision the DISPLAY information
10:19 < lool> From what I understand, xinit starts the server and then a client and it does know about the VT and the DISPLAY
10:19 < lool> It just needs enough power to tell CK about it
10:19 < cjwatson> the display manager could do that - it starts processes inside the display
10:19 < asac> ArneGoetje: do you still need someone who still sees the scim issue?
10:20 < cjwatson> oem-config-dm starts X, a window manager, stuff like gnome-settings-daemon, and the main "greeter" (in this case, oem-config
10:20 < cjwatson> )
10:20 < lool> cjwatson: But when you just "startx", you don't have a DM
10:20 < cjwatson> right, I'm suggesting not using startx
10:21 < lool> Yeah, I got your suggestion about using a DM for our concrete problem right now, but I thought we were back to discussing the CK fix for startx users
10:21 < lool> Since after all this ought to work as well
10:21 < cjwatson> oh, if we're talking *theory*
10:21 < lool> Well would we fix startx we wouldn't have to use a DM either
10:22 < cjwatson> maybe xinit needs to be setuid
10:22 < lool> So I've noted that we have some sample DMs that I could look into, and I think we'll probably use that, but the original problem is about xinit CK awareness
10:22 < cjwatson> and drop privileges when executing the client, obviously
10:22 < lool> Perhaps we could tell CK to please update it's information by looking at DISPLAY?
10:22 < lool> This kind of helper might not need any special rights at all
10:23 < cjwatson> if you can't do OpenSessionWithParameters as root, then logically you ought not to be able to do the same thing in other ways
10:23 < lool> "Hey, I think you should try to connect to :0.0 and see what VT it uses, you might want to add the data you find to your database"
10:23 < cjwatson> if you can, then either consolekit's permissions are too strict, or we are attempting to exploit a security hole
10:23 < cjwatson> which is all very well but not a good thing to build an application around
10:23 < lool> Well OpenSessionWithParameters implies that the params will be trusted
10:24 < lool> While what I'm proposing is that CK be pinged to please refresh its info
10:24 < cjwatson> sorry, I meant "if you can only do OpenSessionWithParameters as root" above
10:24 < cjwatson> CK does have helpers to figure stuff out from an X display
10:24 < lool> Oh perhaps it's the only thing we're missing
10:25 < lool> We have bits to start a session
10:25 < lool> We just need to tell it about VT and DISPLAY of this session
10:25 < lool> Hmm this is probably the security limit
10:25 < cjwatson> you only need to tell it DISPLAY
10:26 < cjwatson> (in theory)
10:26 < ogra_cmpc_> and the content of DISPLAY needs to contain your hostname ... then the session will become active automatically i was told
10:26 < lool> The security limit is probably related to "who are you to tell me what DISPLAY this CK session is using" I guess
10:27 < lool> Ah well, let's just stop at the conclusions that xinit might need to be suid and that we should use a trivial DM for now
10:27 < lool> Thanks all for discussion
10:28 < ogra_cmpc_> thanks for answering my question :)
10:29 < cjwatson> lool: have you tried just calling org.freedesktop.ConsoleKit.Manager.OpenSession?
10:29 < cjwatson> and letting it guess?
10:30 < cjwatson> of course the process that calls that needs to run for the lifetime of the session, otherwise dbus will notice and close the session on you
10:30 < cjwatson> so it can't just be dbus-send
10:30 < cjwatson> (we need a dbus-send --exec=command or something)
10:30 < lool> cjwatson: I didn't try this
10:32 < lool> I wonder why I didn't try to start the session under Xorg
10:32 < cjwatson> it looks in /proc/blah/environ to fish out DISPLAY
10:33 < lool> But just ck-launch-session from within Xorg should simply work
10:33 < ogra_cmpc_> and i wonder why we dont make it mandatory to have that dbus call in x-session-manager ...
10:33 < ogra_cmpc_> that way we wouldnt need to hack up all display managers
10:33 < lool> I'll try to hook it to Xsession.d
10:34 < cjwatson> does ck-launch-session spawn a subprocess with the rest of your session?
10:34 < lool> I don't know; we don't have it; I think it does based on the xinit patch I've seen from fedora
10:35 < lool> http://cvs.fedoraproject.org/viewcvs/devel/xorg-x11-xinit/xinitrc?r1=1.3&r2=1.4
10:35 < cjwatson> yes, it appears to
10:35 < cjwatson> http://gitweb.freedesktop.org/?p=ConsoleKit.git;a=blob;h=73111816d3785996ee25c18dc24e0a3657272428;hb=4740245c6f6137175ef51be2207c35185f4d98f1;f=tools/ck-launch-session.c
10:35 < cjwatson> that would be perfect, then
10:36 < lool> I really have a brain bug
10:36 < cjwatson> it wraps OpenSession, not OpenSessionWithParameters
10:36 < cjwatson> so it doesn't require root
10:36 < lool> So it exactly does what it's supposed to do: look at the DISPLAY of the calling process
10:36 < cjwatson> so the whole discussion above is overengineering :-)
10:36 < lool> Ok, let us ship a Xsession script within consolekit then?
10:37 < cjwatson> hmm, it should only call ck-launch-session if XDG_SESSION_COOKIE isn't already set
10:37 < cjwatson> but yes, that does sound like a good solution
10:37 < lool> Sure