=== robbiew is now known as robbiew-dinner | ||
=== h\h is now known as haraldh | ||
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:11 |
sadmac2 | wasabi_: nobody's gotten around to implementing one | 16:12 |
sadmac2 | wasabi_: su does the trick | 16:13 |
wasabi_ | Ahh. | 16:13 |
wasabi_ | Hmm. Does su end up execing, or does it fork first? | 16:14 |
wasabi_ | Want to make sure upstart's TERM still goes to the right place. | 16:15 |
sadmac2 | su should just exec | 16:15 |
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:17 |
jMCg | Ah. I thought you meant the environment variable. | 16:18 |
wasabi_ | Oh. | 16:18 |
wasabi_ | Using 'su' sure creates a lot of unnecessary processes, though. | 16:24 |
jMCg | wasabi_: whatabout sudo -u $user ? | 16:25 |
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:26 |
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:27 |
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:28 |
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:29 |
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:30 |
jMCg | And script starts this with sudo, but there's no trace of.. | 16:31 |
jMCg | http://dpaste.com/89133/ nope.. no trace of shell or su or sudo or anthing. | 16:32 |
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:39 |
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:53 |
Keybuk | exec su -c "exec command" user | 16:55 |
Keybuk | ;) | 16:55 |
wasabi_ | su stays around. | 16:55 |
Keybuk | yes | 16:55 |
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:56 |
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:58 |
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. | 16:59 |
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:00 |
Keybuk | just need to finish a function | 17:01 |
wasabi_ | okay | 17:01 |
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:11 |
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:12 |
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:13 |
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:14 |
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:15 |
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:17 |
ion | /usr/include/linux/capability.h | 17:18 |
ion | Better: capabilities(7) | 17:19 |
ion | user www-data | 17:21 |
ion | capabilities net-bind-service | 17:21 |
ion | exec /usr/bin/apache2 --foo | 17:21 |
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:42 |
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. | 17:55 |
sadmac2 | Keybuk: so what does the UI for that look like? | 18:00 |
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:01 |
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:02 |
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:03 |
Keybuk | for while, yes | 18:04 |
sadmac2 | Keybuk: ah. That's very different :) | 18:05 |
sadmac2 | Keybuk: and for events is wrong, wrong and terribly wrong. For states it makes perfect sense. | 18:06 |
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:08 |
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:09 |
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:10 |
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:11 |
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:12 |
sadmac2 | ion: well, we certainly have enough douches to clean the mess up. | 18:13 |
ion | *zing* | 18:15 |
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:16 |
sadmac2 | Keybuk: curmudgeons love fedora | 18:18 |
Keybuk | yes, but there's so few of them ;) | 18:19 |
sadmac2 | I wish | 18:19 |
=== robbiew is now known as robbiew-lunch | ||
sadmac2 | Keybuk: you aren't perchance going to JLS? | 18:43 |
sadmac2 | http://gcc.gnu.org/wiki/Var_Tracking_Assignments | 19:01 |
=== robbiew-lunch is now known as robbiew | ||
jMCg | wuhwvmpfzd.. for a second there, I read "JCL" ... | 21:05 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!