Ntfs-3g is using Interix mode on write even when `special_files=wsl`

[ytrezq]

My intent was to work on new files created from Linux inside the wsl1 rootfs. But as the files have an unrelated LXATTRB attribute, ntfs-3g is using Interix mode on chmod/chown despite the special_files=wsl option being passed on the command line.

As the result the files created from mounted ntfs-3g inside the rootfs behave like files created by the Windows explorer and are not readable.

[jpandre]

I would need more information to deal with your issue : 1) which ntfs-3g configuration are you using ? Just run : ntfs-3g 2>&1 | grep ration 2) what are your mount options ? in particular uid, gid, permissions, acl 3) did you configure a UserMapping file ? 4) for which kind of file do you get an unexpected behavior ? (symlink, fifo, etc.) an ntfsinfo output from such a file would be helpful. ntfsinfo -fvF filename device (run as root, with filename being the path within the ntfs tree)

Now, in ntfs-3g chmod and chown are unrelated to the special files mode, as ntfs-3g permissions are designed to interoperate with Windows proper. When you use chmod/chown, ntfs-3g acts on the permissions system of Windows, provided some mapping is defined. This is probably why you find they behave like files created by the Windows explorer.

Wsl has taken another path, inserting posix type data into the file system structure and disregarding the interoperability with Windows. Currently the interoperability of ntfs-3g with wsl is limited to the formatting of special files, with their ownership and permissions still using the Windows way. As wsl appears to be a moving target, better wait for it to settle before going further.

[ytrezq]

@jpandre ah bah oui. Tu as raison, le support de wsl n est que pour les fichiers spéciaux. Je viens de remarquer que tout les fichiers du rootfs appartiennent à root. Je n ai pas utilisé de paramètres pour les permissions et j ai prix le dernier package ntfs-3g de Fedora 37 ce qui signifie la dernière version de ntfs-3g.

Avec wsl2, wsl1 est de facto devenu aussi stable qu Interix sans ajout nouvelle fonctionnalités depuis 2019. Son seul avantage est l intefacage avec les programmes et les pilotes Windows. Wsl2 n a rien a avoir ntfs.

Serait il possible de clarifier la documentation en disant que l attribut étendu $LXUID et $LXMOD n est pas concerné par le paramètre voir, ajouter le support des permissions wsl1?

[jpandre]

Google translate...

@jpandre ah well yes. You're right, wsl support is only for special files. I just noticed that all files in rootfs are owned by root. I didn't use any settings for permissions and I priced the latest ntfs-3g package from Fedora 37 which means the latest version of ntfs-3g.

With wsl2, wsl1 has de facto become as stable as Interix without adding new features since 2019. Its only advantage is the interface with Windows programs and drivers. Wsl2 has nothing to do with ntfs.

Would it be possible to clarify the documentation that the extended attribute $LXUID and $LXMOD is not affected by the parameter, see to add wsl1 permissions support?

Ok for improving the documentation. There is currently no plan to support wsl permissions.

[ytrezq]

@jpandre as alternative, would it be possible to expose $EA handling capabilities ntfs-3g aquired with wsl? I m meaning being at least be able to parse $EA attributes and expose them as xattr like ntfsinfo can do offline?

[jpandre]

would it be possible to expose $EA handling capabilities ntfs-3g aquired with wsl? I m meaning being at least be able to parse $EA attributes and expose them as xattr like ntfsinfo can do offline?

You can access the set of EAs, both for getting and setting, using roughly the same layout as Windows : https://github.com/tuxera/ntfs-3g/wiki/Using-Extended-Attributes#ntfs-ea

Example :

[linux@optiplex testmisc]$ ls -l wsl/fifo
pr-xr-xr-x 1 root root 0 Apr 29 11:38 wsl/fifo
[linux@optiplex testmisc]$ getfattr -e hex -n system.ntfs_ea wsl/fifo
# file: wsl/fifo
system.ntfs_ea=0x1400000000060400244c584d4f4400a411000000

In a program, you would use lgetxattr(2) and siblings, into/from a "struct _FILE_FULL_EA_INFORMATION" as defined in msdn, to access each EA individually.

Note : from Windows 10, both EA and REPARSE can be set on a file, and the current ntfs-3g also allows it.

[ytrezq]

@jpandre not I m meaning to expose the underlying attributes directly or even in my case, provide a way to write to it. The way you describe only works on Windows, not from Linux.

I m not even using C but python/bash. What I m trying to acheive is manual upgrade following https://github.com/microsoft/WSL/issues/8332 because before 2019, wsl used Volfs instead of DrvFs.

[jpandre]

Sorry, this is what I have in store right now...

For your migration, only using bash, can you not :

• either remove the EA set alltogether setfattr -h -x system.ntfs_ea filename
• or force a standard EA set matching your (minimal) needs, after collecting some universal hex ea-value from a specific file : setfattr -h -n system.ntfs_ea -v 0xea-value filename

[ytrezq]

@jpandre correct but if migration fails, I will have to try to downgrade Windows which is even harder and less likely to work. This means I need to keep the LXATTRB attribute while adding the relevant ones.

It appears ntfs-3g is the only things allowing to access $EA from interpreted language as Windows has nothing for this.

This is for a full rootfs. which means there s no generic file permissions in order to get it working, including for the scripts I wrote myself. Proper reading from $LXATTRB is required for rescuing my files and start working again, as well as modifying $EA for adding the relevant attributes while preserving it s existing contents.

But since ntfs-3g supports parsing and modifying $EA for adding a $LXMOD for special wsl files , why not expose this ability to the getfattr/setfattr userspace?

[jpandre]

This means I need to keep the LXATTRB attribute while adding the relevant ones.

Earlier the presence of LXATTRB was the problem. I am lost. What are these relevant attributes ? Would not default values do ? Can you post an ntfsinfo description of what you have and what you want ?

Can you not make a zip of the file tree in its current state using ntfs-3g, and unzip it using Windows ? What attributes would you lose ?

But since ntfs-3g supports parsing and modifying $EA for adding a $LXMOD for special wsl files , why not expose this ability to the getfattr/setfattr userspace?

This is doable of course, but it has not been needed so far, so not requested, not specified, not developed and not planned. Anyway, it is much easier to do at application level than within a file system.

[ytrezq]

This means I need to keep the LXATTRB attribute while adding the relevant ones.

I am lost. What are these relevant attributes ? Would not default values do ? Can you post an ntfsinfo description of what you have and what you want ?

@jpandre Never talked about removing $LXATTRB. Until 2019 or Windows 10 1903, wsl was called bash on Windows and was using only https://github.com/0xbadfca11/lxsstat/wiki/WSL-filesystem#lxattrb for storing everything (including special files which where plain normal Windows files), neverless it supported reading $LXATTRB inside $EA until last week after which the possibility to upgrade to DrvFs automatically was removed altogether through Microsoft update leaving my files unreadable. This result in https://github.com/microsoft/WSL/issues/8332.

Some glibc files as well as some libraries result in programs crashing if they are made executables, there are of course other issues which prevents a 777 permission mode used to rule them all for working everywhere. So for each files, I need to fetch $LXATTRB from $EA and add $LXUID and $LXCHMOD and $LXGID to $EA according to $LXATTRB contents while keeping $LXATTRB as well as potential any Linux xattrs set by third party programs running from bash on Windows.

But since ntfs-3g supports parsing and modifying $EA for adding a $LXMOD for special wsl files , why not expose this ability to the getfattr/setfattr userspace?

This is doable of course, but it has not been needed so far, so not requested, not specified, not developed and not planned. Anyway, it is much easier to do at application level than within a file system.

It depends if you are able to code in C. Ntfs-3g is using fuse, so it should less complex to expose the existing $EA parsing capabilities to userspace, than trying to handle the $EA format securely from scratch.

[jpandre]

So for each files, I need to fetch $LXATTRB from $EA and add $LXUID and $LXCHMOD and $LXGID to $EA according to $LXATTRB contents while keeping $LXATTRB as well as potential any Linux xattrs set by third party programs running from bash on Windows.

This is easier (and safer) to do in an application than within a file system. It is doable in python (if interfaced with lgetxattr(2) and lsetsxattr(2)), otherwise in bash (for getting and setting) and python (for processing).

[ytrezq]

So for each files, I need to fetch $LXATTRB from $EA and add $LXUID and $LXCHMOD and $LXGID to $EA according to $LXATTRB contents while keeping $LXATTRB as well as potential any Linux xattrs set by third party programs running from bash on Windows.

This is easier (and safer) to do in an application than within a file system. It is doable in python (if interfaced with lgetxattr(2) and lsetsxattr(2)), otherwise in bash (for getting and setting) and python (for processing).

Everything I saw is using the Windows api, and there s nothing to write to $EA from Windows. I guess there s must be a reason. There remains undocumented questions on things like if the null terminated attribute name must be 16 bits aligned.

@jpandre you re correct about being safer, but you re already doing it for device files. This means the code required to resist an attacker crafted $EA is there. Just expose it to userspace.