linux-kernel - Re: ntfs3: Folders mounted with 555 permissions?

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] [day] [month] [year] [list]

Message-ID: <15f5e406-f81c-4e78-ba1c-26430d4254a5@gmail.com>
Date: Tue, 30 Jul 2024 13:12:01 +0200
From: Julian Sikorski <belegdol@...il.com>
To: Linux regressions mailing list <regressions@...ts.linux.dev>,
 Konstantin Komarov <almaz.alexandrovich@...agon-software.com>
Cc: ntfs3@...ts.linux.dev, LKML <linux-kernel@...r.kernel.org>
Subject: Re: ntfs3: Folders mounted with 555 permissions?

Hi,

well I would not call it a regression either because it never worked 
properly(*) in the first place. noacsrules option just allowed the 
problem to be worked around.
(*) Properly meaning that, however unlikely, this could be an intended 
behaviour. Having said that, ntfs-3g does not require any special mount 
options or chmod calls to be able to write to Windows' Documents folder.

Best regards,
Julian

Am 29.07.24 um 10:44 schrieb Linux regression tracking (Thorsten Leemhuis):
> Top-posting: adding Konstantin to the list of recipients, he might have
> missed this on the list.
> 
> Side note: this seems to be a regression, but given that it seems only
> few people care and apparently is caused by the removal of a feature not
> working properly beforehand, I don't think this is something covered by
> the no regressions" rule.
> 
> Ciao, Thorsten
> 
> On 27.07.24 22:34, Julian Sikorski wrote:
>> Am 11.07.23 um 10:04 schrieb Julian Sikorski:
>>>
>>> with linux-6.4, now that noacsrules option is gone, an old issue has
>>> become problematic. When I mount my windows drive, some of the folders
>>> in Users are mounted with 555 permissions, including the ones I would
>>> like to edit:
>>>
>>> $ ls -l /mnt/windows/ | grep Users
>>> lrwxrwxrwx. 1 julas julas          8  1. Dez 2018  Documents and
>>> Settings -> ./Users
>>> lrwxrwxrwx. 1 julas julas          8  9. Okt 2022  Dokumente und
>>> Einstellungen -> ./Users
>>> dr-xr-xr-x. 1 julas julas       4096  9. Okt 2022  Users
>>>
>>> $ ls -l /mnt/windows/Users/beleg/ | grep Documents
>>> dr-xr-xr-x. 1 julas julas    8192  7. Jul 15:28 Documents
>>> lrwxrwxrwx. 1 julas julas      24  9. Okt 2022  Eigene Dateien ->
>>> ./../../Users/beleg/Documents
>>> lrwxrwxrwx. 1 julas julas      24  1. Nov 2021  Moje dokumenty ->
>>> ./../../Users/beleg/Documents
>>>
>>> Is this intended behaviour? It appears to be quite an old issue [1].
>>> If so, is there any other fix than running a recursive chmod?
>>>
>>> Best regards,
>>> Julian
>>>
>>> [1]
>>> https://www.reddit.com/r/archlinux/comments/r325t3/permissions_problems_with_the_new_ntfs3_driver/
>>
>> One year later the issue is still there with kernel 6.9.11:
>>
>> $ ls -lh /mnt/windows/Users/beleg/
>> insgesamt 18M
>> dr-xr-xr-x. 1 julas julas    0 19. Jul 2020  '3D Objects'
>> -rwxr-xr-x. 1 julas julas  77K 20. Nov 2022   AMDRM_Install.log
>> -rwxr-xr-x. 1 julas julas 2,7M 20. Nov 2022   AMD_RyzenMaster.log
>> drwxr-xr-x. 1 julas julas    0  2. Dez 2018   ansel
>> lrwxrwxrwx. 1 julas julas   30  9. Okt 2022   Anwendungsdaten ->
>> ./../../Users/beleg/AppData/Roaming
>> drwxr-xr-x. 1 julas julas    0  9. Okt 2022   AppData
>> -rwxr-xr-x. 1 julas julas 1,4K 18. Feb 15:30  aqtinstall.log
>> dr-xr-xr-x. 1 julas julas    0  9. Okt 2022   Contacts
>> lrwxrwxrwx. 1 julas julas   58  9. Okt 2022   Cookies ->
>> ./../../Users/beleg/AppData/Local/Microsoft/Windows/INetCookies
>> lrwxrwxrwx. 1 julas julas   30  1. Nov 2021  'Dane aplikacji' ->
>> ./../../Users/beleg/AppData/Roaming
>> dr-xr-xr-x. 1 julas julas 4,0K 15. Mai 20:41  Desktop
>> dr-xr-xr-x. 1 julas julas 8,0K  5. Jul 22:43  Documents
>>
>> Here are the mount options:
>> /dev/nvme0n1p4 on /mnt/windows type ntfs3
>> (rw,relatime,uid=1000,gid=1000,iocharset=utf8)
>>
>> It is the main issue preventing me from switching away from ntfs-3g. Can
>> I somehow investigate this further to help fixing this?
>>
>> Best regards,
>> Julian
>>