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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Wed, 25 Nov 2020 22:20:37 -0800
From:   Daniel Rosenberg <>
To:     Gabriel Krisman Bertazi <>
Cc:     Eric Biggers <>,
        Gao Xiang <>,
        "Theodore Y . Ts'o" <>,
        Jaegeuk Kim <>,
        Andreas Dilger <>,
        Chao Yu <>,
        Alexander Viro <>,
        Richard Weinberger <>,,,,,,,
Subject: Re: [PATCH v4 2/3] fscrypt: Have filesystems handle their d_ops

> This change has the side-effect of removing the capability of the root
> directory from being case-insensitive.  It is not a backward
> incompatible change because there is no way to make the root directory
> CI at the moment (it is never empty). But this restriction seems
> artificial. Is there a real reason to prevent the root inode from being
> case-insensitive?

> I don't have a use case where I need a root directory to be CI.  In
> fact, when I first implemented CI, I did want to block the root directory
> from being made CI, just to prevent people from doing "chattr +F /" and
> complaining afterwards when /usr/lib breaks.
> My concern with the curent patch was whether this side-effect was
> considered, but I'm happy with either semantics.
> --
> Gabriel Krisman Bertazi

That's just from the lost+found directory right? If you remove it you
can still change it, and then add the lost+found directory back. Isn't
that how it works currently? I definitely didn't intend to change any
behavior around non-encrypted casefolding there.

I should look at what fsck does if you do that and have a LoSt+fOuNd folder...

-Daniel Rosenberg

Powered by blists - more mailing lists