=== robbiew is now known as robbiew-dinner === h\h is now known as haraldh [16:11] So why doesn't upstart have a 'user' stanza? [16:11] I can imagine it being hard for pid 1 to do namemapping, yeah. [16:12] wasabi_: nobody's gotten around to implementing one [16:13] wasabi_: su does the trick [16:13] Ahh. [16:14] Hmm. Does su end up execing, or does it fork first? [16:15] Want to make sure upstart's TERM still goes to the right place. [16:15] su should just exec [16:17] wasabi_: you need a TERM? More importantly: upstart has a TERM!? [16:17] stop sends TERM, n o? [16:17] sigterm. [16:18] Ah. I thought you meant the environment variable. [16:18] Oh. [16:24] Using 'su' sure creates a lot of unnecessary processes, though. [16:25] wasabi_: whatabout sudo -u $user ? [16:26] wasabi_: huh? [16:26] wasabi_: su shouldn't create any additional processes methinks [16:26] Maybe your various wrappers do. [16:26] 'su' keeps running, and it creates a shell to run the specified command in. [16:26] Since the -c option is a shell script. [16:27] wasabi_: check the manpage. there should be a way to make that not happen [16:27] Doesn't seem to. [16:27] either way it shouldn't "create" a shell. It should exec() a shell [16:27] "-c will cause the next argument to be treated as a command by most command interpreters. The command will be executed by the shell specified in /etc/passwd for the target user." [16:27] Well, it's not. Clearly. [16:28] and yeah, stopping it sends sigterm to the wrong place. [16:28] Heh. [16:28] fun [16:28] Now, one could try to specify -s /binhrmpfzd... bleh. exec is a shell-builtin.... [16:29] Yeah. No way to pass an arg list though [16:29] Oh I see [16:29] Anyways, I'm pretty much very sure (because I myself abuse it) that sudo does not start a funky shell. [16:29] jmcg@metis ~ % ps -cafe|grep -i [s]udo [16:29] 1 jmcg@metis ~ % [16:30] As opposed to (and I'm only giving a grep -c here): jmcg@metis ~ % ps -cafe| grep -c [h]ttpd [16:30] 91 [16:31] And script starts this with sudo, but there's no trace of.. [16:32] http://dpaste.com/89133/ nope.. no trace of shell or su or sudo or anthing. [16:39] Can't get sudo to run from upstart though. Grrr. [16:39] Ahh. I see [16:39] -c on sudo does not support args. [16:39] it tries to exec the string, and finds no command. [16:53] Argh. And I can't use -g in sudo. Says the root user isn't allowed to do it. [16:53] And I'm not going to monkey with perms. [16:55] exec su -c "exec command" user [16:55] ;) [16:55] su stays around. [16:55] yes [16:56] but the process group is the same [16:56] Oh [16:56] so init sends SIGTERM to both su and its child process [16:58] From what I can tell the child does get it. [16:58] Begins a shutdown process (which can take awhile) [16:58] ANd then init reports it exists with 255. [16:58] exits [16:58] And the child keeps shutting down. [16:58] So su is disappearing. [16:59] oh, right [16:59] yeah that can happen [16:59] Uh huh. [16:59] it's not ideal [16:59] Sure isn't. [17:00] I think a 'user' stanza added to upstart would make me happy. [17:00] it wouldn't make me happy [17:00] Name lookup? [17:00] no, it's wrong [17:00] Oh. Why? [17:00] give me 30s and I'll describe how I see it working ;) [17:01] just need to finish a function [17:01] okay [17:11] right [17:11] so "run as user" means lots of different things [17:11] for example, a user's cron job [17:11] that doesn't just run setuid the user [17:11] but it runs *as* the user [17:11] it's setuid, initgroups() is used *and* PAM is invoked to set up a full user session [17:12] and Upstart needs to support user owned jobs that behave in this fashion [17:12] *separate* to that is the notion of dropping privileges [17:12] dropping privileges may include calling setuid() [17:13] but that's a numpty's function [17:13] what you really want to specify is the real *and* effective uids of the job [17:13] and any capabilities to retain [17:13] Hmm [17:13] I see. [17:14] for example, you should be able to say that named runs with real and effective "bind" but retains CAP_NET_BIND_SERVICE [17:14] So it's obviously more complicated than just user. [17:14] yes [17:14] and then there's the permission side of ti [17:15] as "scott", I should be able to send init commands to start and stop my jobs [17:15] or start and stop jobs that I am permitted to start and stop, which runs as my user [17:15] Yeah. [17:15] and that then brings the problem of security on a job [17:15] and interestingly, means that the "user" of a job need not be specified in the config [17:15] (or "any user" for example) [17:17] keybuk: Did whatshisnick talk to you about Linux capabilities? In Solaris SMF, he said, you can declare a job to run as an unprivileged user but with the rights to open port <1024 for instance. Linux has equivalent capabilities functionality, Upstart would just need to implement support for that along with the rest of the run-as-user functionality. [17:18] /usr/include/linux/capability.h [17:19] Better: capabilities(7) [17:21] user www-data [17:21] capabilities net-bind-service [17:21] exec /usr/bin/apache2 --foo [17:42] right [17:42] that's exactly what I was waffling about above [17:42] though I wouldn't use "user" there [17:42] it's more "real uid www-data" ;) [17:55] Hah, now that i actually look at the discussion, i realize i was just repeating what was already said. I’ve been watching a movie and missed the discussion; just noticed something about the ”user” of a job and mentioned what jmcg talked about recently. [18:00] Keybuk: so what does the UI for that look like? [18:01] Keybuk: To play devils advocate, a "user" stanza would do something that most end users would understand. There's a very simple expectation for the behavior of that. [18:01] that's the bit I don't know [18:02] right [18:02] and I want the simple expectation to always fail [18:02] which is why I want to avoid a "user" stanza [18:03] Keybuk: we should probably discuss the "and" operator while I'm thinking of it. You want to keep it around and non-deprecated last I brought it up? [18:04] for while, yes [18:05] Keybuk: ah. That's very different :) [18:06] Keybuk: and for events is wrong, wrong and terribly wrong. For states it makes perfect sense. [18:08] right [18:08] while something and something or someting [18:08] on foo [18:08] on bar [18:08] on baz [18:08] hourly [18:08] at the hour of scampering [18:08] 40 minutes after tea [18:09] etc. [18:09] all of the "event" bits are OR [18:09] if you want AND [18:09] from event until SOME OTHER EVENT and while something [18:09] on foo [18:10] Keybuk: 0.6 compatibility means we have to keep AND around, which hurts since ripping it out deletes about 1/4 of upstart's code :) [18:10] yeah [18:10] its kinda-sorta less painful with triggers. [18:11] but then you guys never went with 0.6 anyway, did you? :p [18:11] we didn't... so there is that... [18:11] which means you have nice crasher bugs [18:11] but hey ;) [18:12] you picked a bad time in our release cycle for 0.6 :( [18:12] you picked a bad time in your release cycle to ship a version of init with known serious bugs ;) [18:12] also our system is kind of dependent on state transfer working (even the broken version we got) [18:12] All the major Linux distributions should live together for a while, so their periods would get synchronized. [18:13] ion: well, we certainly have enough douches to clean the mess up. [18:15] *zing* [18:16] Keybuk: there's bugs and then there's bug reports. The loudest userbase in linux is staying quiet on upstart. Life is good. [18:16] loudest userbase? :) [18:18] Keybuk: curmudgeons love fedora [18:19] yes, but there's so few of them ;) [18:19] I wish === robbiew is now known as robbiew-lunch [18:43] Keybuk: you aren't perchance going to JLS? [19:01] http://gcc.gnu.org/wiki/Var_Tracking_Assignments === robbiew-lunch is now known as robbiew [21:05] wuhwvmpfzd.. for a second there, I read "JCL" ...