[14:56] <akscram> Hi, how can I run the job under special user and group?
[15:06] <JanC_> akscram: use 'su'
=== JanC_ is now known as JanC
[15:23] <akscram> JanC: 10x, but for user without shell I must run su with -s option but it is potential security risk
[15:26] <akscram> interest question is why upstart natively not support optional execution jobs under non-privileged users
[15:28] <wraiden> because most of the services out there are capable of dropping priviledges and no one stepped up to implement a user change? sysv init even doesn't support this by it self...
[15:30] <wraiden> would be a huge can of worms to implement that. one needs to pull in pam if one want to support environmental updates on user change...
[15:30] <akscram> I no try compare SysV and upstart but this problem is important
[15:32] <wraiden> writ a sh script for it and include that in your job config
[15:32] <JanC> akscram: what exactly would be the security risk?
[15:46] <akscram> JanC: service potential have vulnerabilities and attacker can have user with shell to run some operation
[15:48] <JanC> if the service has vulnerabilities, doesn't that already pose the same problem?
[15:51] <akscram> wraiden: interesting but it is no solution give the user to decide the problem itself
[15:52] <akscram> yes I wrote script..end script becouse I haven't other solutions
[15:56] <akscram> JanC: I say potentialy but all known problems are fixed in the service
[15:57] <JanC> what I mean is: _when_ there is a security problem in a service, then it doesn't really matter whether you use su or something else...?
[16:09] <akscram> JanC: exactly but in breaking case attacker have more possibilities in one case
[16:59] <JanC> I don't see exactly what extra possibilities that would give, but maybe I'm looking over it...