linux-kernel - Re: [PATCH v2 08/10] fs/ntfs3: Add Kconfig, Makefile and doc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 23 Aug 2020 12:16:43 +0200
From:   Pali Rohár <pali@...nel.org>
To:     Konstantin Komarov <almaz.alexandrovich@...agon-software.com>
Cc:     "viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH v2 08/10] fs/ntfs3: Add Kconfig, Makefile and doc

On Friday 21 August 2020 16:25:37 Konstantin Komarov wrote:
> +Mount Options
> +=============
> +
> +The list below describes mount options supported by NTFS3 driver in addtion to
> +generic ones.
> +
> +===============================================================================
> +
> +nls=name		These options inform the driver how to interpret path
> +			strings and translate them to Unicode and back. In case
> +			none of these options are set, or if specified codepage
> +			doesn't exist on the system, the default codepage will be
> +			used (CONFIG_NLS_DEFAULT).
> +			Examples:
> +				'nls=utf8'
> +
> +uid=
> +gid=

IIRC ntfs filesystem had concept of storing unix owner/group. Was it
dropped? Or it is incompatible with current Windows implementation? I'm
just curious if we cannot use ntfs-native unix permissions instead of
forcing them from mount options. Maybe as improvement for future.

Normally owner/group on ntfs is stored in that windows SID format.
ntfs-3g fuse driver has some mount option where you can specify mapping
table between SID and unix to make permissions compatible with existing
windows installations.

Such functionality could be a nice feature once somebody would have time
to implement it in future...

> +umask=			Controls the default permissions for files/directories created
> +			after the NTFS volume is mounted.
> +
> +fmask=
> +dmask=			Instead of specifying umask which applies both to
> +			files and directories, fmask applies only to files and
> +			dmask only to directories.
> +
> +nohidden		Files with the Windows-specific HIDDEN (FILE_ATTRIBUTE_HIDDEN)
> +			attribute will not be shown under Linux.

What other people think? It is useful mount option which would disallow
access to hidden files? Hidden attribute is normal attribute which even
normal user without admin rights on Windows can set on its own files.

Also concept of hidden files is already present for fat filesystems and
we do not have such mount option nor for msdosfs, vfat nor for exfat.

Konstantin, what is purpose of this mount option? I would like to know
what usecases have this option.

> +sys_immutable		Files with the Windows-specific SYSTEM
> +			(FILE_ATTRIBUTE_SYSTEM) attribute will be marked as system
> +			immutable files.
> +
> +discard			Enable support of the TRIM command for improved performance
> +			on delete operations, which is recommended for use with the
> +			solid-state drives (SSD).
> +
> +force			Forces the driver to mount partitions even if 'dirty' flag
> +			(volume dirty) is set. Not recommended for use.
> +
> +sparse			Create new files as "sparse".
> +
> +showmeta		Use this parameter to show all meta-files (System Files) on
> +			a mounted NTFS partition.
> +			By default, all meta-files are hidden.
> +
> +no_acs_rules		"No access rules" mount option sets access rights for
> +			files/folders to 777 and owner/group to root. This mount
> +			option absorbs all other permissions:
> +			- permissions change for files/folders will be reported
> +				as successful, but they will remain 777;
> +			- owner/group change will be reported as successful, but
> +				they will stay as root

What about rather adding "mode=" and "dmode=" mount option which would
specify permissions for all files and directories? Other filesystems
have support for "mode=" mount option and I think it is better if
filesystems have some "common" options and not each filesystem its own
mount option for similar features.

> diff --git a/fs/ntfs3/Kconfig b/fs/ntfs3/Kconfig
> new file mode 100644
> index 000000000000..92a9c68008c8
> --- /dev/null
> +++ b/fs/ntfs3/Kconfig
> @@ -0,0 +1,23 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +config NTFS3_FS
> +	tristate "NTFS Read-Write file system support"
> +	select NLS
> +	help
> +	  Windows OS native file system (NTFS) support up to NTFS version 3.1.
> +
> +	  Y or M enables the NTFS3 driver with full features enabled (read,
> +	  write, journal replaying, sparse/compressed files support).
> +	  File system type to use on mount is "ntfs3". Module name (M option)
> +	  is also "ntfs3".
> +
> +	  Documentation: <file:Documentation/filesystems/ntfs3.rst>
> +
> +config NTFS3_64BIT_CLUSTER
> +	bool "64 bits per NTFS clusters"
> +	depends on NTFS3_FS && 64BIT
> +	help
> +	  Windows implementation of ntfs.sys uses 32 bits per clusters.
> +	  If activated 64 bits per clusters you will be able to use 4k cluster
> +	  for 16T+ volumes. Windows will not be able to mount such volumes.

Would it be possible to change this compile time option into mount
option?

Because I do not see any benefit in compile time option which makes
kernel's ntfs driver "fully" incompatible with Windows implementation.

For me it looks like that mount option for such functionality is more
suitable.