On 04/01/2022 20.18, Michael Orlitzky wrote:
On Tue, 2022-01-04 at 19:26 +0100, Piotr Karbowski wrote:

And none of which happens unless you intentionally trigger it.

...

Sure, acl and how chmod manipulate mask on ACL-enabled entities is not
very simple, but nothing will break by itself just because you have acl
support enabled, you would need to try very hard to run into problems.



Even if you're right, and if no other tools invoke tar, and the user is
smart enough not to copy/paste commands from the web, and if no other
archivers can extract ACLs when invoked directly or indirectly...
you're still burdening the user to either have faith that this is all
true, or to verify it himself. Repeat the argument for other flags like
ipv6, and you wind up requiring either a lot of faith, or a lot of
diligence, both of which are antithetical to basic principles of
security.

You may not buy the argument, but it's why people disable this stuff,
and the ability to disable it is why a lot of our users user Gentoo to
begin with.

I was challenging here your opinion that most people should disable acl support.

And what I showed is that, by keeping it enabled, does not bring on you potential problems beside possible security issues in the code that you keep around and not want to have around.

Sure, there are valid reasons to strip things from kernel, I've seen some tor nodes running kernel without input devices all out of initramfs, such usecase do make sense.

However I am strongly against opinion that most people should not enable acl, unless you have 16 MB NOR flash storage and every kB of kernel image counts, but then it's unlikely that you'd use gentoo there in the first place, since bundling headers and whole toolchain would east a lot of storage.

I know there are people who love to disable things, there are even people who says that pam is bloatware and strip it, or people who, security reason as they claim, refuse to use logind provider (elogind or systemd) and instead choose to run Xorg as root.

-- Piotr.

Reply via email to