写入权限为0777的文件失败 [英] Fail to write file with permission 0777

问题描述

我正在以0777的权限将文件写入unix上的磁盘，但是 ls -la 显示它具有 -rwxr-xr-x ，这是不期望的.>

  err = ioutil.WriteFile(path，jsonByte，0777)如果err！= nil {log.Print(错误)} 

我希望获得 -rwxrwxrwx 权限.我不明白为什么缺少 w 权限.

解决方案

首先，作为一些Unix操作系统在此处清除了setuid/setgid ).

Unix/Linux文件权限通过使操作系统清除从程序的权限中删除的所有用户请求权限起作用.请求被批准.

也就是说，在调用创建新文件的文件系统操作时，您将使用代码提供一种模式.在这种情况下，您提供的 0777 实际上是 rwxrwxrwx .

但是，与此同时，用户的操作环境 ¹ 包含另一个八进制模式，称为 解决方案

First, as Burak Serdar notes in a comment, be sure that this really is a new file, as the OS will generally leave the existing permissions in place when overwriting an existing file (though the details are OS-specific, and in particular some Unix-ish OSes clear setuid/setgid here).

Unix/Linux file permissions work by having the OS clear any permissions that the user requests be removed, from the permissions that the program requests be granted.

That is, when calling a file system operation that creates a new file, you, in your code, supply a mode. In this case you are supplying 0777 which is indeed rwxrwxrwx.

Meanwhile, however, the user's operating environment¹ contains another octal mode called the umask. In this case it is presumably 022, or ----w--w-. These permissions are removed from your supplied permissions: 0777 & (^022) is 0755 which is rwxr-xr-x. So the newly created file has mode rwxr-xr-x, or 0755, even though your program asked for 0777.

For this reason, most Unix programs should use one of two modes during file creation operation: 0777 for directories and executable files, and 0666 for non-executable files. The user's umask will remove unwanted permissions: users who want privacy can set their umask to 077 which will remove rwx for both group and other, leaving only 0700 or 0600 as appropriate.

One exception to this rule is that any program that wants to ensure extra privacy—such as ssh-related code, when it creates key-pairs—should supply its mode as 0600 so that there are no group and other-user permission bits set in the first place.

Note that chmod calls do not have the user's umask setting applied. If you need to discover the user's umask to compute the correct value for a chmod call, use either the new golang.org/sys/x/unix Umask function, or the old syscall Umask function. Unfortunately you must supply a new umask to discover the original umask. This displaces the per-process umask until you re-install the original value. Hence, you might want to do this in an init function and store the result in a variable for safekeeping while also restoring the original:

var Umask int

func init() {
    Umask = unix.Umask(0777)
    unix.Umask(Umask)
}

for instance (assuming the new-style; the old style syscall.Umask usage is identical; neither returns any error). This makes your program Unix-specific, though.

---

¹This means permissions stored in the kernel's per-process data, not shell-style environment variables.

这篇关于写入权限为0777的文件失败的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！