'l'文件权限中的位 ( ---x--l--- )O/P
当我创建时,我有时会获得一些文件权限,但不是定期获得 文件 int fd = open("\tmp\lockfile", O_CREAT | O_EXCL);
。我得到的 O/P 很稀有 场景当我这样做时 ll \tmp\locfile
是
root@cool> ll lockfile
---x--l--- 1 root nms 0 Feb 21 10:40 lockfile
root@cool>`
虽然大多数时候 O/P 是这样的:-
root@cool> ll importer.lck
---------- 1 user nms 0 Feb 22 10:58 importer.lck`
我知道通过 O_CREAT 创建文件 虽然不提供模式可能是一个问题 以上可能是一个问题。在这种情况下:-
root@cool> ll lockfile
---x--l--- 1 root nms 0 Feb 21 10:40 lockfile
root@cool>
一旦创建此文件的进程结束,我将无法删除锁定文件。 chmod 在上述情况下也不起作用,但 chown 似乎起作用。
我如何防止使用这些权限创建文件 ---x--l---
是否只是通过传递模式?面具套装是:-
root@cesme:/tmp# umask
0022
root@cesme:/tmp#`
I am getting a l bit in file permission sometimes but not regulaly When i create
file With int fd = open("\tmp\lockfile", O_CREAT | O_EXCL);
. The O/P that i get in rare
scenario When i do ll \tmp\locfile
is
root@cool> ll lockfile
---x--l--- 1 root nms 0 Feb 21 10:40 lockfile
root@cool>`
While most of the time O/P is this :-
root@cool> ll importer.lck
---------- 1 user nms 0 Feb 22 10:58 importer.lck`
I know creating file through O_CREAT While not providing the mode can be an issue as done
above can be an issue . In this case:-
root@cool> ll lockfile
---x--l--- 1 root nms 0 Feb 21 10:40 lockfile
root@cool>
i am not able to delete the lockfile once the process Which created this is over`.
chmod also does not work in above case but chown seems to work .
How can i prevent creating the file with these permission ---x--l---
is it just by passing mode ? The mask set is :-
root@cesme:/tmp# umask
0022
root@cesme:/tmp#`
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
您省略了 open() 所需的第三个参数,即模式。 (使用O_CREAT时该参数是必需的)。由于堆栈上没有参数,因此 open 使用随机值(即堆栈上的返回地址)。
You omitted the required third parameter of open(), which is mode. (The parameter is required when you use O_CREAT). Since there's no parameter on the stack, open uses a random value (i.e. the return address on the stack).
artensay - 不。OP
搞乱了强制锁定,这是非常错误的。你可能没有读过他的其他帖子。然而,该位的设置是来自辅助调用,例如 fcntl() 语句,而不是堆栈垃圾。是的,你是对的,公开声明是错误的。
artensay - No.
The OP was messing with mandatory locking, very incorrectly. You may not have read his other posts. However that bit got set it was from an ancillary call like an fcntl() statement, not stack garbage. And yes, you are correct, the open statement was wrong.