public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Patrik Schindler <poc@pocnet.net>
Cc: Jan Kara <jack@suse.cz>,
	linux-ext4@vger.kernel.org, Ted Tso <tytso@mit.edu>
Subject: Re: ext4: Remove deprecated noacl/nouser_xattr options
Date: Tue, 17 Jan 2023 11:45:25 +0100	[thread overview]
Message-ID: <20230117104525.kmbypv4vca6lbd5a@quack3> (raw)
In-Reply-To: <3C7004E8-E732-40C1-B0DD-2A2290E43AC5@pocnet.net>

Hello Patrik!

On Mon 16-01-23 13:25:07, Patrik Schindler wrote:
> Am 16.01.2023 um 11:42 schrieb Jan Kara <jack@suse.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@suse.com>
SUSE Labs, CR

  reply	other threads:[~2023-01-17 10:45 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <A5F622F8-99CF-4C7D-8811-7D82DB1C8846@pocnet.net>
2023-01-16 10:42 ` ext4: Remove deprecated noacl/nouser_xattr options Jan Kara
2023-01-16 12:25   ` Patrik Schindler
2023-01-17 10:45     ` Jan Kara [this message]
2023-01-17 10:55       ` Patrik Schindler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230117104525.kmbypv4vca6lbd5a@quack3 \
    --to=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=poc@pocnet.net \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox