linux-ext4 - Re: ext4: Remove deprecated noacl/nouser

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:   Tue, 17 Jan 2023 11:45:25 +0100
From:   Jan Kara <jack@...e.cz>
To:     Patrik Schindler <poc@...net.net>
Cc:     Jan Kara <jack@...e.cz>, linux-ext4@...r.kernel.org,
        Ted Tso <tytso@....edu>
Subject: Re: ext4: Remove deprecated noacl/nouser_xattr options

Hello Patrik!

On Mon 16-01-23 13:25:07, Patrik Schindler wrote:
> Am 16.01.2023 um 11:42 schrieb Jan Kara <jack@...e.cz>:
> 
> > On Sun 15-01-23 23:56:21, Patrik Schindler wrote:
> >> sorry for contacting you directly, but I struggle to find relevant
> >> information on this topic.
> > 
> > This is best discussed on ext4 development mailing list (added to CC).
> 
> Am I required to join that list?

No, the list is open so anyone can post to it.

> >> In this web page is documented that "noacl" for ext4 is deprecated.
> >> 
> >> https://patchwork.ozlabs.org/project/linux-ext4/patch/1658977369-2478-1-git-send-email-xuyang2018.jy@fujitsu.com/
> >> 
> >> Do you have some background information at hand why noacl is deprecated,
> >> and how to get the functionality of noacl after this change?
> > 
> > Yes, these options were deprecated for a long time (10 years) and now they are removed since nobody complained. The reasoning is in commit f70486055ee ("ext4: try to deprecate noacl and noxattr_user mount options"):
> > 
> > No other file system allows ACL's and extended attributes to be enabled
> > or disabled via a mount option.  So let's try to deprecate these
> > options from ext4.
> 
> Understood.
> 
> > And it makes sense to me. It looks a bit strange and dangerous to
> > disable (part of) permission checks for the files. What usecase did you
> > have for it?
> 
> I'm using Debian Linux 11.
> 
> When copy Files from my Mac via Samba to ext4 volumes, ACLs get added.
> (Much) earlier, this wasn't the case, and just UNIX permissions were in
> effect. For me, UNIX permissions are totally sufficient, and I can easily
> see what's going on with ls -l. For ACLs, I need to individually fiddle
> with get/setfacl.
> 
> This feels cumbersome to me and gives me a sense not having immediate
> control over access rights. Thus I'd like to find a way to get the
> previous behavior back. Ideally without recompiling samba to remove ACL
> support, as outlined here:
> https://serverfault.com/questions/828977/how-can-i-stop-samba-from-writing-extended-acls
> 
> For a very long time I had noacl in my fstab but with the update to
> Debian 11, I saw the message about the deprecation. Not sure when I
> observed ACLs being actually written by Samba, though.
> 
> In addition, even newer Google hits almost entirely state "noacl in fstab
> to suppress ACLs for ext4", so I'm probably not the only one trying to
> disable them and people largely failed to understand that noacl has no
> effect anymore.

I understand the wish for more overview over file permissions but this
seems like a bit awkward way to reach it? It rather seems like a lack of
control in the smbget(1) tool (or whatever you are using for the copying)?
Adding an option there to not copy permissions from the server would look
like a very logical thing to do (similarly as cp(1) has these options)...
Would that work?

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR