忽略 umask 的新贵“独角兽”
我正在使用 upstart v1.4 启动我的应用程序服务器，它称为 unicorn< /代码>。
upstart 配置文件如下所示：
description "Unicorn Application Server"
start on network
stop on runlevel [!2345]
umask 0003
setuid unicorn
setgid myproject
chdir /opt/myproject/
respawn
exec /opt/myproject/bin/unicorn --config-file /opt/myproject/config/unicorn.rb --env production
进程必须以 0774 运行，即 ug+rwxo+r，至少对于目录而言。用户&组是共享的，例如 nginx 服务器、上传、员工登录等。
我观察到目录是使用错误的权限创建的：
drw-rw-r-- 2 unicorn myproject 4096 2012-01-13 06:58 20120113-0658-7704-4676
据我所知，我的应用程序中没有任何内容导致此问题。
根据将gdb附加到进程，并调用call umask(0)，有效的umask为75，或0o113代码>.
这是 gdb 会话：
root@1:/opt/myproject# cat ./tmp/pids/unicorn.pid
7600
root@1:/opt/myproject# gdb
GNU gdb (GDB) 7.1-ubuntu
(gdb) attach 7600
Attaching to process 7600
(gdb) call umask(0)
$1 = 75
(gdb) call umask(75)
$2 = 0
(gdb) q
Quit anyway? (y or n) y
Detaching from program: /usr/local/bin/ruby, process 7600
root@1:/opt/myproject# ruby -e 'printf("%o\n", 75)'
113
113 的 umask 将考虑对 664 的权限，这似乎就是我所看到的。
我在这里做错了什么，独角兽行为不端吗？暴发户是否忽略了我的节？我应该将节定义为 003，而不是 0003 吗？我的 gdb 会话是否有效，并且 %o printf() 语法是否正确？
I'm using upstart v1.4 to start my application server, it's called unicorn.
The upstart configuration file looks like this:
description "Unicorn Application Server"
start on network
stop on runlevel [!2345]
umask 0003
setuid unicorn
setgid myproject
chdir /opt/myproject/
respawn
exec /opt/myproject/bin/unicorn --config-file /opt/myproject/config/unicorn.rb --env production
It's essential that the process run with 0774, that is ug+rwxo+r, at least for directories. User & Group are shared as such as the nginx server, uploads, staff logging in, etc.
I have observed that the directories are created with the wrong permissions:
drw-rw-r-- 2 unicorn myproject 4096 2012-01-13 06:58 20120113-0658-7704-4676
So far as I am aware, nothing in my application is causing this.
According to attaching gdb to the process, and calling call umask(0), the effective umask is 75, or 0o113.
Here's the gdb session:
root@1:/opt/myproject# cat ./tmp/pids/unicorn.pid
7600
root@1:/opt/myproject# gdb
GNU gdb (GDB) 7.1-ubuntu
(gdb) attach 7600
Attaching to process 7600
(gdb) call umask(0)
$1 = 75
(gdb) call umask(75)
$2 = 0
(gdb) q
Quit anyway? (y or n) y
Detaching from program: /usr/local/bin/ruby, process 7600
root@1:/opt/myproject# ruby -e 'printf("%o\n", 75)'
113
The umask of 113 would account for permissions being made to 664, which appears to be what I'm seeing.
What am I doing wrong here, is Unicorn misbehaving? Is upstart ignoring my stanza? Should I be defining the stanza as 003, not 0003? Is my gdb session work, and %o printf() syntax correct?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
“独角兽”在新贵环境之外表现如何？我猜想完全一样，但请检查这一点（让一切尽可能简单）。
请记住，umask 值不是绝对值：顾名思义，它是一个掩码 - 它会从应用程序在打开文件或创建目录时指定的权限位中“减去”权限位。 Upstarts umask stanza 的行为从我所看到的来看，所以你的问题一定是这个独角兽应用程序在打开文件进行写入和创建目录时指定了一组奇怪的权限位（模式）。
尝试 stracing unicorn 看看它实际上在做什么：
等待 unicorn 创建一些文件和/或目录后，停止/杀死它并查看文件
/tmp/strace.log。grep for "open (FILE)”，其中 FILE 是它创建的文件之一的名称，例如，看看 open 系统调用的第三个参数是什么。当您拥有该模式值时，应该可以构造一个 umask 值来授予您所需的文件权限。请注意，这确实假设 unicorn:如果在执行上述过程后，您仍然认为 Upstart 存在问题，请提供一个简单的测试用例（不需要 unicorn）并在此处提出错误：https://bugs.launchpad.net/upstart/+filebug。
How does "unicorn" behave outside of an Upstart environment? I would guess exactly the same but please check this (keep everything as simple as possible).
Remember that a umask value is not an absolute: as the name suggests, it is a mask - it "subtracts" permission bits from the permission bits your application specifies when it opens a file or creates a directory. Upstarts umask stanza is behaving from what I can see so your problem must be with this unicorn application specifying what is to you an odd set of permission bits (mode) when it opens files for writing and creates directories.
Try stracing unicorn to see what it is actually doing:
Having waited for unicorn to create some files and/or directories, stop/kill it and look at file
/tmp/strace.log.grep for "open(FILE)" where FILE is the name of one of the files it creates for example and see what the 3rd argument is to the open system call. When you have that mode value it should be possible to construct a umask value to give the file permissions you desire. Note that this does assume that unicorn:If -- after having following the process above -- you still think there is an issue with Upstart, please provide a simple test case (that does not require unicorn) and raise a bug here: https://bugs.launchpad.net/upstart/+filebug.
如果您不从 exec 节调用 unicorn，而是调用一个仅调用“umask >> /tmp/somefile”的脚本，那么它会在其中放入什么？如果这给出了预期的响应，那么你的问题就出在独角兽身上。
If you instead of calling unicorn from the exec stanza call a script that just calls "umask >> /tmp/somefile" what does it put in there? If that gives the expected response, your problem is in unicorn.