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