[00:30] ion: I have updated my branch to meet your review comments [00:30] Great, thanks [00:31] do you think this a feature thats likely to get merged? [00:36] There’s definitely demand for that, and it would be nice to have while full PAM support is still in TODO. The change isn’t invasive either. Ultimately it’s up to Keybuk, though. [00:37] coll thanks [00:37] doh [00:37] *cool [00:37] There are still some function calls in the “foo()” style instead of “foo ()”. Oh, and the first instance of JOB_PROCESS_ERROR_SETUID is probably a typo, it should be _USER i guess. [00:37] space between function (parms)? [00:37] Yeah, that’s the coding style in Upstart. [00:37] ion: "for that" ? [00:38] keybuk: For setuid support in jobs. https://code.edge.launchpad.net/~goraxe/upstart/user_sid/+merge/31905 [00:39] randomly quick comments [00:39] "user" should be "uid" (since it's set uid, not PAM user support) [00:39] should support "uid 1000" as well as "uid messagebus" [00:39] setgid? initgroups? [00:42] user -> uid sure can do, setgid yep, spotting uid \d vs \w ... may need some advice, initgroups guessing that sets up non primary group member ship? [00:43] all group membership in fact [00:43] if you just setuid() like that, it'll still be gid 0 [00:43] which may have surprising consequences permissions-wise [00:43] yep can see that [00:45] hmm, actually, can't remember whether initgroups sets the primary group or not ;) [00:46] I will check the manpage for usage [00:46] The man page only seems to talk about the supplementary group list. [00:46] ta [00:46] :-) [00:47] you may need to setgid (user->pw_gid) as well [00:47] in which case, definitely add a "gid" support in too [00:47] if gid not set use ->pw_gid ? [00:50] should uid and gid be looked up at parse time instead of job spawn time? [00:50] exactly [00:50] hmm [00:50] looking up user and group ids is complex [00:51] at parse time is when init starts, you almost certainly don't have nsswitch by then ;-) [00:51] LDAP, Kerberos, etc. won't be up [00:51] (no network, for a start!) [00:51] one bright side of doing this in job_process is that it's also done in a child, so any issues just prevent spawning, rather than holding up or crapping up the init daemon [00:52] sure you get no cacheing, but then setuid isn't really common enough to cache [00:52] certainly if any two services spawned *share* a uid (benefit to cacheing) they're probably doing it wrong from a security POV [00:53] my use case for this is entirly for local user services, and we have a LDAP/kerberos env [00:54] basicly we have started using exec su -c ... which i think is quite ugly ... [00:54] yeah, su gives you a PAM session though [00:54] which may be what you want [00:56] hmm ... you may have a point ... I think for our trivial cases we just want to spawn daemons at statup keep em running if they crash, and do some basic priv dropping [00:56] ie this would be a good start, but I agree would not cover all cases [00:56] how much of the pam stuff have you got scoped out? [00:57] the PAM stuff is easy [00:57] thinking about how a user of the same uid would restart a service - that's hard :) [00:57] the "uid"/"gid" stuff is just a property of a system service in this case, so just required someone to care enough to implement it [00:57] I've no problem with applying it into the next 0.6 release once it's ready [00:58] cool, thanks [01:00] on that note I really should call it a night [12:28] hi [18:41] hello there, i was wondering if there is any list of integrated upstart signals such as "start on net-device-added" or "start on filesystem" available ? === Md_ is now known as Md [23:44] ion, Keybuk: I have done some more work to change to uid & gid stanza [23:45] I'm having a bit of a problem with initgroups though [23:49] it seems to only work if the process is running as root, even chmod +s on the file did not give it enough perms [23:49] the file being test_job_process