显然可以使用susudo来进行暴发户更改用户ID并以正常身份运行脚本的规范方法是什么,但这似乎很麻烦(并且可以生成不必要的日志行)。

#1 楼

在新贵v1.4中,配置文件本身支持setuid和setgid。

评论


有关详细信息,请参见食谱:upstart.ubuntu.com/cookbook/#run-a-job-as-a-a-different-user

–詹森·纳瓦雷特(Jason Navarrete)
2012年10月25日16:32

换句话说,Precise(12.04)和更高版本中都支持它。

–爱德华·安德森(Edward Anderson)
13年1月19日在3:24

换句话说,centos 6不支持

–套接字对
2013年12月26日下午6:43

作为记录,请使用initctl --version查找当前版本的新贵。

–马恩
2014年8月29日在12:14

令人讨厌的是,AWS上的Amazon Linux发行版使用RHEL 6的新贵版本(0.6.5 !!!!),因此使用该版本的任何人都必须使用'su'解决方案。

–阿斯范·卡兹
16年2月2日在16:35

#2 楼

在freenode上的#upstart频道上询问,此事的正式说法是:


Upstart的未来版本将对此提供本机支持,但就目前而言,
您可以使用类似的方法:

exec su -s /bin/sh -c 'exec "q4312078q" "$@"' username -- /path/to/command [parameters...]



评论


这是唯一适用于Amazon Linue EC2的答案(我尝试了sudo和su的所有变体,包括--session-command,-c,ad nauseum);一旦启动,它们都不允许停止进程;非常感谢。

–加藤
2011-12-02 10:42

那是一些花哨的贝壳魔法,+ 1。

– Steve Kehlet
2014年8月4日在16:56

这在CentOS 6(新贵0.6.5)上对我不起作用。 su发起了一系列fork(我认为深度为4),这意味着期望fork甚至期望守护进程都无法捕获最终的PID。

–马克·拉卡塔(Mark Lakata)
2014年8月27日在21:54

我在Amazon Linux(Upstart 0.6.5)上使用它来启动Jenkins进程(值得庆幸的是,它并未守护自己),并且可以正常工作!我必须对其稍作更改,以将标准输出重定向到日志文件并设置一些环境变量,但它确实有效!我的版本如下:exec su -s / bin / sh -c'HOME = / foo / bar exec“ $ 0”“ $ @”&> / var / log / foobar.log'用户名-/ path / to / command [参数...]

–阿斯范·卡兹
16年2月2日在17:05

对于CentOS 6,请在下面查看hxysayhi的答案。解决了马克·拉卡塔(Mark Lakata)确定的问题

–bitsoflogic
20年1月21日在15:41

#3 楼

如何使用start-stop-daemon?

exec start-stop-daemon --start --chuid daemonuser --exec /bin/server_cmd


来自Upstart食谱:


Debian和Ubuntu系统的推荐方法是使用助手实用程序start-stop-daemon。 […] start-stop-daemon不会对其启动的过程施加PAM(“可插入身份验证模块”)限制。


注意:RHEL不支持start-stop-daemon

评论


如果需要,您也可以使用该组。使用--chuid daemonuser:daemongroup

–Evgeny
2011年5月30日15:33

#4 楼

有几种方法可以做到,所有方法的语义都略有不同,特别是与组成员身份有关:




setuidgid将把您置于您指定的组中。


原始daemontools的setuidgid仅将您置于该组中,因此您将无法访问属于您所属的其他组的文件。
来自daemontools-encore的setuidgid和来自nosh工具集的setuidgid都具有一个-s(aka --supplementary)选项,该选项会将您放入该组,也将您置于所有指定用户的补充组中。 >

一旦成为特权较低的用户,使用newgrp会将一个组添加到您的组集中,但还会创建一个新的子shell,这使得在脚本内部使用变得很棘手。
start-stop-daemon保存您的组成员身份,而不仅仅是setuid / setgid。
chpst -u username:group1:group2:group3... commandname可以让您确切指定要采用的组成员身份,但是(在Ubuntu中)它仅与runit软件包一起提供,可以替代upstart
su -c commandname usernamesudo -u username commandname一样,都选择了用户名的所有组成员身份,所以他们是显然是达到最少惊讶的途径。


#5 楼

使用包装setuidgid中的daemontools

此处的文档:http://cr.yp.to/daemontools/setuidgid.html

评论


daemontools不是暴发户的先决条件,因此这似乎不是“规范”的答案

–亚当·尼尔森(Adam Nelson)
2010年1月8日在21:52

此外,daemontools位于Universe(ubuntu 10.04)中,而upstart位于main中。

– jtimberman
2010年8月14日在18:18

#6 楼

在Amazon EC2上的Ubuntu 10.10实例上,我最好使用start-stop-daemon命令。

我还遇到了其他一些新贵的问题。我正在调用具有特定virtualenv和执行程序的一些参数的python应用程序。

以下是对我有用的方法。

script
  export PYTHONPATH=.:/home/ubuntu/.local/lib/python2.7/site-packages/:/home/ubuntu/python/lib/python2.7/site-packages/
  exec start-stop-daemon --start  --chuid ubuntu --exec /home/ubuntu/python_envs/MyProj/bin/python /home/ubuntu/www/MyProj/MyProj.py -- --config-file-dir=/home/ubuntu/www/MyProj/config/ >> /home/ubuntu/startup.log 2>&1 &
end script


PYTHONPATH将在此暴发作业运行时从源安装一些软件包到PYTHON模块路径。我必须在绝对路径中进行所有操作,因为chdir节似乎没有起作用。

评论


我还遇到了与exec start-stop-daemon一起使用的env变量的问题。

–托马斯·布拉特(Thomas Bratt)
13年8月6日在11:30

#7 楼

我使用的是CentOS 6,我无法获得推荐的破解工具(适用于Upstart 0.6.5),也无法使用``su''技巧,因为涉及的分叉数量(我认为是4)没有被``期望分叉''跟踪'或'期待守护程序'。

我最终只是做了

chown user:group executable
chmod +s executable


(即设置setuid位并更改所有权)。

这可能不是最安全的方法,但是对于内部研发项目而言,这对我们而言并不重要。

评论


如果您要在其中执行chmod 1700或至少执行chmod u + sx,go-x而不是仅+ s,则可以认为它“足够安全”。 :)

–dannysauer
2015年10月2日在22:33



#8 楼

在CentOS 6中,新贵0.6.5对我有用。

script

    exec su user_name << EOF
        exec /path/to/command [parameters...]
EOF

end script


或:

script

    exec su user_name << EOF
       ..... what you want to do ....
EOF

end script


使用时

exec su -s /bin/sh -c 'exec "
1. the job forked and the main process is not tracked.
2. the main process changed its process group,because of `su -c`
" "$@"' username -- /path/to/command [parameters...]


initclt stop无法停止作业过程。
我认为原因是:

q4312078q

#9 楼

根据您要实现的目标,还有第三种可能性。您也许可以放宽有关文件/设备上的访问控制。这样可以允许没有特权的用户安装或访问他们通常不被允许的物品。只需确保您没有在此过程中放弃该王国的钥匙即可。

您还可以更改sudo密码缓存的超时。但是我不建议您这样做,除非您的计算机在物理上是安全的(例如,您认为路人不太可能尝试获得sudo访问权限)。

有一个很好的理由,那就是:执行特权操作的几种方法,以及执行不必要的必要日志记录的方法。宽松的限制将对您的系统造成安全隐患,而缺少日志记录将意味着您无法知道受到威胁时发生了什么。

如果您担心日志文件的大小那么可能是错误的。在正常情况下,Sudo每次使用仅生成一行。