Bug 223846
| Summary: | msdosfs does not reflect READONLY to user | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | karl | ||||
| Component: | kern | Assignee: | freebsd-fs (Nobody) <fs> | ||||
| Status: | New --- | ||||||
| Severity: | Affects Many People | CC: | cem, damjan.jov | ||||
| Priority: | --- | Keywords: | patch | ||||
| Version: | 11.0-STABLE | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
I committed it to CURRENT shortly after posting it: r326031 Bruce raised some concerns, but in his typical long-winded fashion that I haven't had the energy to parse. I think he would prefer READONLY not be reflected in mode flags, but I'm not sure why. He does point out that showing a readonly mode flag does not prevent applications from writing to these files. Maybe it should. (In reply to Conrad Meyer from comment #1) I would argue it should; what's the point of a read-only flag if it's ignored If you're going to have a permission system then IMHO it ought to be enforced, such as it is and within the constraints of the underlying file system (e.g. in the case of msdosfs the "owner" is effectively synthetic and there is no such thing as "group" or "other".) Yeah, I agree with you. Created attachment 192866 [details]
deny writing to READONLY files in msdosfs
Hi. Here is my patch to deny writing to files with the READONLY attribute on msdosfs filesystems. It just affects the file_mode variable in msdosfs_access(). My tests show writing and appending to READONLY files is successfully denied the same way on ufs, zfs, and msdosfs.
|
As documented on freebsd-fs in response to a query I posted after observing the above behavior msdosfs does not reflect the READONLY attribute on files in an msdosfs-mounted filesystem back to userspace. This means that while you can set the READONLY attribute on a file with chmod a subsequent "stat" of that file (from a program), or a display with "ls" will not reflect it in the file mode returned. Conrad Meyer posted a short code snippet that would fix this; credit to him of course on the identification but IMHO this should be changed globally and MFC'd as appropriate. --- a/sys/fs/msdosfs/msdosfs_vnops.c +++ b/sys/fs/msdosfs/msdosfs_vnops.c @@ -287,6 +287,8 @@ msdosfs_getattr(struct vop_getattr_args *ap) vap->va_fileid = fileid; mode = S_IRWXU|S_IRWXG|S_IRWXO; + if ((dep->de_Attributes & ATTR_READONLY) != 0) + mode &= ~(S_IWUSR|S_IWGRP|S_IWOTH); vap->va_mode = mode & (ap->a_vp->v_type == VDIR ? pmp->pm_dirmask : pmp->pm_mask); vap->va_uid = pmp->pm_uid;