Linux may_open open_flag验证与O_TRUNC截断处理

Linux may_open是VFS层打开文件路径上的权限和标志验证关卡位于fs/namei.c。它在do_dentry_open之前执行负责对用户传入的open_flags做语义合规性检查以及O_TRUNC截断条件的判定。任何不满足内核策略的flag组合都会在此被拒绝。// fs/namei.cint may_open(struct user_namespace *mnt_userns, struct path *path,int acc_mode, int flag){struct dentry *dentry path-dentry;struct inode *inode dentry-d_inode;int error;if (!inode)return -ENOENT;switch (inode-i_mode S_IFMT) {case S_IFLNK:return -ELOOP;case S_IFDIR:if (acc_mode MAY_WRITE)return -EISDIR;if (flag O_CREAT)return -EISDIR;break;case S_IFBLK:case S_IFCHR:if (!(flag O_NODEV) !(flag O_PATH))return -EACCES;break;}error inode_permission(mnt_userns, inode, acc_mode);if (error)return error;error security_file_open(file);if (error)return error;if (flag O_TRUNC) {error handle_truncate(mnt_userns, dentry);if (error)return error;}return 0;}may_open的第一步是根据inode的文件类型做快速拒绝。符号链接在open路径上不允许出现因为路径查找阶段已完成解引用。目录不允许以写入模式打开O_WRONLY/O_RDWR因为目录的写入只能通过rename、unlink等目录操作接口完成。块设备和字符设备在没有O_NODEV标志时拒绝打开这是内核的安全策略确保非特权用户不能直接访问设备节点。// fs/namei.cstatic int inode_permission(struct user_namespace *mnt_userns,struct inode *inode, int mask){int ret;if (unlikely(mask MAY_WRITE)) {if (IS_IMMUTABLE(inode))return -EPERM;if (IS_APPEND(inode) (mask MAY_APPEND))return -EPERM;}ret do_inode_permission(mnt_userns, inode, mask);if (ret)return ret;ret security_inode_permission(inode, mask);if (ret)return ret;return 0;}inode_permission对写权限做了额外限制如果inode设置了IMMUTABLE标志通过chattr i任何写请求都被拒绝如果设置了APPEND_ONLY标志chattr a同时请求的不是追加写MAY_APPEND也要拒绝。这就是为什么O_WRONLY打开一个chattr a的文件会失败而O_APPEND打开却可以成功。O_TRUNC的处理是may_open中最具破坏性的操作。当open的标志包含O_TRUNC且文件是普通文件时内核需要将文件大小截断为零。// fs/open.cstatic int handle_truncate(struct user_namespace *mnt_userns,struct dentry *dentry){const struct inode_operations *i_op dentry-d_inode-i_op;int error;if (!(dentry-d_inode-i_mode S_IFREG))return 0;if (i_op-truncate) {// 旧的 truncate 方法已废弃error i_op-truncate(dentry);} else {struct iattr newattrs;newattrs.ia_size 0;newattrs.ia_valid ATTR_SIZE | ATTR_CTIME;error notify_change(mnt_userns, dentry, newattrs, NULL);}return error;}handle_truncate有两种实现路径。如果inode_operations定义了truncate方法这是旧接口新文件系统不应使用直接调用之否则通过notify_change传递ATTR_SIZE给文件系统的setattr接口。notify_change调用链最终到达ext4_setattr或xfs_setattr这些函数会释放文件原有的数据块并重置i_size。O_TRUNC的触发有几个关键约束条件。may_open本身要求调用方具备MAY_WRITE权限。此外如果文件是以O_APPEND方式打开的某些内核版本和文件系统会屏蔽O_TRUNC因为APPEND语义要求写入总是在文件末尾追加与截断矛盾。// fs/open.c 中的 do_dentry_open 调用前int complete_walk(struct nameidata *nd){// ...}struct file *path_openat(struct nameidata *nd, const struct open_flags *op,unsigned flags){// ...error may_open(nd-path, op-acc_mode, op-open_flag);if (!error) {file do_dentry_open(nd-path, op-open_flag, current_cred());// ...}return file;}may_open返回0后do_dentry_open才真正创建file结构体、调用文件系统的open方法。这种check-then-act的顺序保证了在open方法执行任何副作用之前所有的权限和语义校验都已经完成。O_TRUNC在多线程并发打开同一文件时的行为值得关注。handle_truncate中notify_change会获取inode锁inode_lock因此在两个线程同时O_TRUNC打开同一文件时第二个线程会等待第一个线程完成截断和inode锁释放后才执行。最终文件大小取决于后完成的那个truncate调用——但两者都将大小设为0所以结果是确定的。may_open中的security_file_open是LSM钩子允许安全模块在文件实际打开前施加策略。例如SELinux可以通过file_permission钩子检查进程的安全上下文是否允许打开目标文件。这个检查在O_TRUNC的handle_truncate之前执行避免无权限的进程触发不必要的截断I/O。最后需要注意的是O_PATH标志。当open带有O_PATH时may_open会跳过几乎所有权限检查仅执行基本文件类型判断。因为O_PATH打开的文件不用于读写操作只作为路径引用的句柄后续通过fstatat、execveat等系统调用间接使用。