Re: [PATCH] locks: print a warning when mount fails due to lack of "mand" support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu 15-08-19 16:27:18, Jeff Layton wrote:
> Since 9e8925b67a ("locks: Allow disabling mandatory locking at compile
> time"), attempts to mount filesystems with "-o mand" will fail.
> Unfortunately, there is no other indiciation of the reason for the
> failure.
> 
> Change how the function is defined for better readability. When
> CONFIG_MANDATORY_FILE_LOCKING is disabled, printk a warning when
> someone attempts to mount with -o mand.
> 
> Also, add a blurb to the mandatory-locking.txt file to explain about
> the "mand" option, and the behavior one should expect when it is
> disabled.
> 
> Reported-by: Jan Kara <jack@xxxxxxx>
> Signed-off-by: Jeff Layton <jlayton@xxxxxxxxxx>

Looks good to me. You can add:

Reviewed-by: Jan Kara <jack@xxxxxxx>

								Honza

> ---
>  Documentation/filesystems/mandatory-locking.txt | 10 ++++++++++
>  fs/namespace.c                                  | 11 ++++++++---
>  2 files changed, 18 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/filesystems/mandatory-locking.txt b/Documentation/filesystems/mandatory-locking.txt
> index 0979d1d2ca8b..a251ca33164a 100644
> --- a/Documentation/filesystems/mandatory-locking.txt
> +++ b/Documentation/filesystems/mandatory-locking.txt
> @@ -169,3 +169,13 @@ havoc if they lock crucial files. The way around it is to change the file
>  permissions (remove the setgid bit) before trying to read or write to it.
>  Of course, that might be a bit tricky if the system is hung :-(
>  
> +7. The "mand" mount option
> +--------------------------
> +Mandatory locking is disabled on all filesystems by default, and must be
> +administratively enabled by mounting with "-o mand". That mount option
> +is only allowed if the mounting task has the CAP_SYS_ADMIN capability.
> +
> +Since kernel v4.5, it is possible to disable mandatory locking
> +altogether by setting CONFIG_MANDATORY_FILE_LOCKING to "n". A kernel
> +with this disabled will reject attempts to mount filesystems with the
> +"mand" mount option with the error status EPERM.
> diff --git a/fs/namespace.c b/fs/namespace.c
> index 6464ea4acba9..602bd78ba572 100644
> --- a/fs/namespace.c
> +++ b/fs/namespace.c
> @@ -1643,13 +1643,18 @@ static inline bool may_mount(void)
>  	return ns_capable(current->nsproxy->mnt_ns->user_ns, CAP_SYS_ADMIN);
>  }
>  
> +#ifdef	CONFIG_MANDATORY_FILE_LOCKING
>  static inline bool may_mandlock(void)
>  {
> -#ifndef	CONFIG_MANDATORY_FILE_LOCKING
> -	return false;
> -#endif
>  	return capable(CAP_SYS_ADMIN);
>  }
> +#else
> +static inline bool may_mandlock(void)
> +{
> +	pr_warn("VFS: \"mand\" mount option not supported");
> +	return false;
> +}
> +#endif
>  
>  /*
>   * Now umount can handle mount points as well as block devices.
> -- 
> 2.21.0
> 
-- 
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux