Rollup merge of #101644 - Timmmm:file_permissions_docs, r=thomcc
Document surprising and dangerous fs::Permissions behaviour on Unix This documents the very surprising behaviour that `set_readonly(false)` will make a file *world writable* on Unix. I would go so far as to say that this function should be deprecated on Unix, or maybe even entirely. But documenting the bad behaviour is a good first step. Fixes #74895
This commit is contained in:
commit
214fa9fb9c
@ -1365,6 +1365,34 @@ pub fn set_modified(mut self, t: SystemTime) -> Self {
|
||||
impl Permissions {
|
||||
/// Returns `true` if these permissions describe a readonly (unwritable) file.
|
||||
///
|
||||
/// # Note
|
||||
///
|
||||
/// This function does not take Access Control Lists (ACLs) or Unix group
|
||||
/// membership into account.
|
||||
///
|
||||
/// # Windows
|
||||
///
|
||||
/// On Windows this returns [`FILE_ATTRIBUTE_READONLY`](https://docs.microsoft.com/en-us/windows/win32/fileio/file-attribute-constants).
|
||||
/// If `FILE_ATTRIBUTE_READONLY` is set then writes to the file will fail
|
||||
/// but the user may still have permission to change this flag. If
|
||||
/// `FILE_ATTRIBUTE_READONLY` is *not* set then writes may still fail due
|
||||
/// to lack of write permission.
|
||||
/// The behavior of this attribute for directories depends on the Windows
|
||||
/// version.
|
||||
///
|
||||
/// # Unix (including macOS)
|
||||
///
|
||||
/// On Unix-based platforms this checks if *any* of the owner, group or others
|
||||
/// write permission bits are set. It does not check if the current
|
||||
/// user is in the file's assigned group. It also does not check ACLs.
|
||||
/// Therefore even if this returns true you may not be able to write to the
|
||||
/// file, and vice versa. The [`PermissionsExt`] trait gives direct access
|
||||
/// to the permission bits but also does not read ACLs. If you need to
|
||||
/// accurately know whether or not a file is writable use the `access()`
|
||||
/// function from libc.
|
||||
///
|
||||
/// [`PermissionsExt`]: crate::os::unix::fs::PermissionsExt
|
||||
///
|
||||
/// # Examples
|
||||
///
|
||||
/// ```no_run
|
||||
@ -1390,8 +1418,40 @@ pub fn readonly(&self) -> bool {
|
||||
/// using the resulting `Permission` will update file permissions to allow
|
||||
/// writing.
|
||||
///
|
||||
/// This operation does **not** modify the filesystem. To modify the
|
||||
/// filesystem use the [`set_permissions`] function.
|
||||
/// This operation does **not** modify the files attributes. This only
|
||||
/// changes the in-memory value of these attributes for this `Permissions`
|
||||
/// instance. To modify the files attributes use the [`set_permissions`]
|
||||
/// function which commits these attribute changes to the file.
|
||||
///
|
||||
/// # Note
|
||||
///
|
||||
/// `set_readonly(false)` makes the file *world-writable* on Unix.
|
||||
/// You can use the [`PermissionsExt`] trait on Unix to avoid this issue.
|
||||
///
|
||||
/// It also does not take Access Control Lists (ACLs) or Unix group
|
||||
/// membership into account.
|
||||
///
|
||||
/// # Windows
|
||||
///
|
||||
/// On Windows this sets or clears [`FILE_ATTRIBUTE_READONLY`](https://docs.microsoft.com/en-us/windows/win32/fileio/file-attribute-constants).
|
||||
/// If `FILE_ATTRIBUTE_READONLY` is set then writes to the file will fail
|
||||
/// but the user may still have permission to change this flag. If
|
||||
/// `FILE_ATTRIBUTE_READONLY` is *not* set then the write may still fail if
|
||||
/// the user does not have permission to write to the file.
|
||||
///
|
||||
/// In Windows 7 and earlier this attribute prevents deleting empty
|
||||
/// directories. It does not prevent modifying the directory contents.
|
||||
/// On later versions of Windows this attribute is ignored for directories.
|
||||
///
|
||||
/// # Unix (including macOS)
|
||||
///
|
||||
/// On Unix-based platforms this sets or clears the write access bit for
|
||||
/// the owner, group *and* others, equivalent to `chmod a+w <file>`
|
||||
/// or `chmod a-w <file>` respectively. The latter will grant write access
|
||||
/// to all users! You can use the [`PermissionsExt`] trait on Unix
|
||||
/// to avoid this issue.
|
||||
///
|
||||
/// [`PermissionsExt`]: crate::os::unix::fs::PermissionsExt
|
||||
///
|
||||
/// # Examples
|
||||
///
|
||||
@ -1405,7 +1465,8 @@ pub fn readonly(&self) -> bool {
|
||||
///
|
||||
/// permissions.set_readonly(true);
|
||||
///
|
||||
/// // filesystem doesn't change
|
||||
/// // filesystem doesn't change, only the in memory state of the
|
||||
/// // readonly permission
|
||||
/// assert_eq!(false, metadata.permissions().readonly());
|
||||
///
|
||||
/// // just this particular `permissions`.
|
||||
|
Loading…
Reference in New Issue
Block a user