On Thu, 8 Feb 2024 22:27:02 -0600, Grant Taylor
<gtaylor@tnetconsulting.net> wrote in
<uq49im$4q9$4@tncsrv09.home.tnetconsulting.net>:

> Doing something to enable case confusion and prefixing PATH with a . are
> a Bad Idea (TM).

I agree with the latter opinion, but beg to differ regarding
your "case confusion" conclusion.

I just tried this on my own system, and I recommend you do
the same with a loopback-mounted file.

The way -F folding works, you can't have a directory entry for
"foo" and "FOO". Examples:

# cp foo FOO
cp: 'foo' and 'FOO' are the same file

# ll
total 0
-rw-r--r-- 1 root root 0 Feb 8 22:19 BAR
-rw-r--r-- 1 root root 0 Feb 8 22:18 foo

# > FOO

# ll
total 0
-rw-r--r-- 1 root root 0 Feb 8 22:19 BAR
-rw-r--r-- 1 root root 0 Feb 8 22:24 foo

# mkdir BAR
mkdir: cannot create directory ‘BAR’: File exists
_ _ _ _ _ _ _

...and so forth.

So it seems to me that the only problem you've
illuminated is the "'.' in PATH problem", your
opinion of which I agree with.

--
-v

Grant Taylor <gtaylor@tnetconsulting.net> writes:
> On 2/8/24 04:58, Richard Kettlewell wrote:
>> What’s the threat model here?
>
> It's different for different people.
>
>> If an attacker can put a hostile command sU in /usr/bin, they must have
>> been able to write /usr/bin, in which case they could just replace
>> /usr/bin/su with their own version. They don’t need a case-insensitive
>> filesystem to do that.
>
> The examples I gave were exactly that, overt examples meant to
> demonstrate a concept. There are MANY subtle ways that this type of
> thing can bite you.

Such as...

> What if someone has `.` as the first directory in their PATH
> (.:/usr/local/bin:/usr/bin:/bin type thing) and the are in (their
> current working directory is) /tmp, and someone places a file named
> `SU` -- which is a wrapper around /bin/su -- and the person runs `su`
> to do something. The person unwittingly / inadvertently ran /tmp/SU
> instead of the expected /bin/su.

As with your previous example, the attack works just as well on a
case-sensitive filesystem: the attacker just creates /tmp/su. (For this
reason it’s been common advice not to put ‘.’ in PATH since at least the
last century.)

> There are multiple things that work in concert with each other to
> result in unexpected and likely unwanted behavior of the system. Each
> of the things is in and of itself innocuous enough. But combined
> ... unwanted things can easily, if not likely, happen.
>
> Depending exactly on how the case folding works, what library is used
> when someone needs to load libnss_dns.so:
>
> /lib/LIBNSS_DNS.SO
> /lib/LiBnSs_DnS.sO
> /lib/libnss_dns.so

There are real examples with that structure but once again, I don’t
think Lawrence was advocating doing it for /.

That said, it’s possible that the majority of Unix laptop/desktop
installs run a case-insensitive /, and while they do have problems with
(for example) git cloning the linux kernel, there doesn’t seem to be a
stream of security issues as a result.

> What if two users named Bob exist on the system from when case folding
> wasn't enabled:
>
> /home/BOB
> /home/bob
>
> Case folding is enabled.
>
> Eliding authentication issues, which home directory is used?

That one is well into “play stupid games, win stupid prizes”. If your
policy for naming home directories (or anything else) generates names
that differ only in letter case, why would you choose to enable
case-insensitive matching?

--
https://www.greenend.org.uk/rjk/

Grant Taylor <gtaylor@tnetconsulting.net> writes:
> On 2/8/24 08:14, Richard Kettlewell wrote:
>> However I don’t see Lawrence advocating doing it to whole system
>> (i.e. /) so much as individual volumes or even directories.
>
> Lawrence didn't give any indication on the scope of where the setting
> would be used save for at the file system level and a vague reference
> to a directory.
>
> Without further guidance, it's natural to assume that it's the file
> system mount point -> entire file system.

What’s natural is personal and situational. Assuming the worst possible
interpretation of a text is probably a sensible thing to do in a
high-stakes contract negotiation, but it really doesn’t seem like a good
strategy in an informal discussion.

--
https://www.greenend.org.uk/rjk/

On 08/02/2024 21:16, Carlos E.R. wrote:

> In current day Windows you can name files with upper, lower, mixed case.
> No matter how you do it, in Windows it is the same file. It is simply a
> prettier file name.
>

Oh? Same as Apple then,

I thought Winders had grown out of that.

--
"When one man dies it's a tragedy. When thousands die it's statistics."

Josef Stalin

On 08/02/2024 22:11, Lawrence D'Oliveiro wrote:
> On Thu, 8 Feb 2024 09:42:56 +0000, The Natural Philosopher wrote:
>
>> I once mistakenly added a case sensitive disk to an Apple OS/X machine.
>> Applications promptly stopped working.
>
> That’s the opposite of what we’re discussing here.

But it's the same issue, just the other way around. Either case matters
inside the code you are using or it doesn't. Switching that over makes
stuff break.

If you specify a lower case file name and you get an uppercase filename,
it breaks your code.

--
The urge to save humanity is almost always a false front for the urge to
rule.
– H. L. Mencken, American journalist, 1880-1956

On 09/02/2024 01:04, Grant Taylor wrote:
> On 2/8/24 08:04, Richard Kettlewell wrote:
>> Grant seems to think it is; he explicitly mentioned security.
>
> Security is the most obvious / easiest place to demonstrate problems
> that arise from case confusion.
>
>
>
Frankly I dont think it is, but there ya go.

I think breaking of applications is more likely.

--
"Socialist governments traditionally do make a financial mess. They
always run out of other people's money. It's quite a characteristic of them"

Margaret Thatcher

On 2/9/24 00:29, vallor wrote:
> The way -F folding works, you can't have a directory entry for "foo"
> and "FOO".

You don't need different cased files of the same name in the same directory.

All you need is the directory that contains the file in the case that
differs from what you typed earlier in the PATH than the directory that
contains the file in the case that you did type.

Any directory and any file name suffices to be kicked by this case
confusion problem.

There are many ways for this to be arranged to happen.

- too many people run things they download without reviewing them -
they can easily modify the PATH a number of ways.
- people can naively add a world writable directory to their PATH
- NFS mounts in the PATH can be compromised at the source
- someone could walk up to your terminal before a screen saver kicks
in after you walk away
- copying and pasting from web pages with embedded control codes to
hide commands in what is pasted

System security or safety or stability is all about doing as many things
as possible to minimize exposure and chance of problems.

As such, doing as many things as possible to avoid potential problems or
contributing to a larger problem is Good Thing (TM). Not enabling
something that could allow case confusion falls into that just like not
prepending your PATH with `.`.

--
Grant. . . .

On 2/9/24 03:13, Richard Kettlewell wrote:
> That one is well into “play stupid games, win stupid prizes”. If
> your policy for naming home directories (or anything else) generates
> names that differ only in letter case, why would you choose to enable
> case-insensitive matching?

It's not always the same person that does both things. It's not always
even remotely close together.

Three consultants ago may have used /home/BOB as part of a migration to
/home/bob for $SOME_REASON (restoration from backup?). One or more
intermediate consultants come and go. The new consultant reads about an
option that they think will simplify case and enables something. Now
/home/bob and /home/BOB case confusion smacks them in the face.

--
Grant. . . .

On 2/8/24 23:42, Lawrence D'Oliveiro wrote:
> How come?

I no longer remember why it was unclear at the time. 1) observers
effect combined with the rest of the thread 2) I've slept since then.

But I know that I was unclear / uncertain about the scope of what you
were talking about.

--
Grant. . . .

On 2/9/24 03:17, Richard Kettlewell wrote:
> What’s natural is personal and situational. Assuming the worst
> possible interpretation of a text is probably a sensible thing to do
> in a high-stakes contract negotiation, but it really doesn’t seem
> like a good strategy in an informal discussion.

I've had a very good career out of assuming the worst (whatever will be
the most work and / or take the longest) while hoping for the best
(whatever will be the least work and / or take the least amount of time).

On 2/8/24 23:41, Lawrence D'Oliveiro wrote:
> Here’s what the OP said:

No ... that's not what the OP said, nor was that the OP.

You, Lawrence, are the /original/ /poster/ of this long thread.

The Natural Philosopher is who made the comment about Apple OS/X.

--
Grant. . . .

On 2/9/24 04:02, The Natural Philosopher wrote:
> But it's the same issue, just the other way around. Either case matters
> inside the code you are using or it doesn't. Switching that over makes
> stuff break.
>
> If you specify a lower case file name and you get an uppercase filename,
> it breaks your code.

EXACTLY!!!

How much damage and if you care about what breaks is independent of the
fact that it breaks.

Some things, like small speakers, just sound a little funny when parts
of them break. Other things like damns cause catastrophic levels of
damage when they break.

--
Grant. . . .

On 2024-02-09 02:12, Grant Taylor wrote:
> On 2/8/24 15:16, Carlos E.R. wrote:
>> The point is, you never know what script or program may create or
>> access a file of the same name but different case as another part of
>> the program or another program. You can never be sure.
>
> Yep.
>
>> That's feasible. For a Samba share, it would be desirable, it can
>> avoid trouble in Windows programs that expect case to not matter.
>
> Samba (et al.) is (are) special case wherein the daemon does the case
> folding, not the underlying file system.
>
> IMHO this is the proper place to handle this type of conversion.

I remember a report describing a problem precisely because somehow two
different case files appeared within the samba scope. I don't remember
the details.

--
Cheers, Carlos.

On Fri, 9 Feb 2024 10:08:26 -0600, Grant Taylor
<gtaylor@tnetconsulting.net> wrote in
<uq5ilq$okd$1@tncsrv09.home.tnetconsulting.net>:

> On 2/9/24 00:29, vallor wrote:
>> The way -F folding works, you can't have a directory entry for "foo"
>> and "FOO".
>
> You don't need different cased files of the same name in the same
> directory.
>
> All you need is the directory that contains the file in the case that
> differs from what you typed earlier in the PATH than the directory that
> contains the file in the case that you did type.
>
> Any directory and any file name suffices to be kicked by this case
> confusion problem.
>
> There are many ways for this to be arranged to happen.
>
> - too many people run things they download without reviewing them -
> they can easily modify the PATH a number of ways.
> - people can naively add a world writable directory to their PATH -
> NFS mounts in the PATH can be compromised at the source - someone
> could walk up to your terminal before a screen saver kicks
> in after you walk away
> - copying and pasting from web pages with embedded control codes to
> hide commands in what is pasted
>
> System security or safety or stability is all about doing as many things
> as possible to minimize exposure and chance of problems.
>
> As such, doing as many things as possible to avoid potential problems or
> contributing to a larger problem is Good Thing (TM). Not enabling
> something that could allow case confusion falls into that just like not
> prepending your PATH with `.`.

And again, your argument about PATHs is quite
orthogonal from a problem with casefold ext4
filesystem directory hierarchies.

If you have to worry about someone dropping "." in your PATH, or
someone adding a trusted command in a PATH directory before
(say) /sbin, then you have bigger problems.

And if someone were to build a system with a casefolded
/sbin, and "su" lives there, then writing a malicious
"SU" into the directory won't do anything but overwrite
"su". But that's not a problem with the casefolding,
that's a problem with permissions and
how PATH is set.[*]

The "elegant" part of the chattr +F scheme: you can't
just turn it on for a directory -- the directory has
to be empty. That means rules about what files get added
are enforced. I encourage anyone to create a test filesystem
in a file to play around with how it behaves.

$ truncate -s 100M testfs.ext4
$ mkfs.ext4 -E encoding=utf8 testfs.ext4

....then you mount it -oloop,rw, cd
into it, make a test directory, and chattr +F
the test directory.

[*] I use bash -- adjust "PATH" variable name to suit your
preferences. :)

--
-v

On Fri, 09 Feb 2024 09:13:39 +0000, Richard Kettlewell wrote:

>> /home/BOB
>> /home/bob
>
> That one is well into “play stupid games, win stupid prizes”. If your
> policy for naming home directories (or anything else) generates names
> that differ only in letter case, why would you choose to enable
> case-insensitive matching?

Maybe one Bob is known as “shouty Bob”, hence the uppercase name.

Hey, how do I know what company the OP keeps ...

On Fri, 9 Feb 2024 10:17:13 -0600, Grant Taylor wrote:

> I've had a very good career out of assuming the worst ...

But what you assume has to be actually possible. If you have to start
assuming impossible things ... then, maybe, a nice, comfortable padded
cell is the safest place for you.

On Fri, 9 Feb 2024 10:19:51 -0600, Grant Taylor wrote:

> On 2/8/24 23:41, Lawrence D'Oliveiro wrote:
>
>> Here’s what the OP said:
>
> No ... that's not what the OP said, nor was that the OP.

You are referring to the wrong posting. Check what I said again.

On Fri, 9 Feb 2024 10:02:58 +0000, The Natural Philosopher wrote:

> On 08/02/2024 22:11, Lawrence D'Oliveiro wrote:
>> On Thu, 8 Feb 2024 09:42:56 +0000, The Natural Philosopher wrote:
>>
>>> I once mistakenly added a case sensitive disk to an Apple OS/X
>>> machine.
>>> Applications promptly stopped working.
>>
>> That’s the opposite of what we’re discussing here.
>
> But it's the same issue, just the other way around. Either case matters
> inside the code you are using or it doesn't. Switching that over makes
> stuff break.

If your stuff is already written to be cross-platform-compatible with
Apple’s or Microsoft’s platforms, then it will have already dealt with
this.

If the code is written to not care whether the filesystem is case-
sensitive or not, then it will work either way.

Standard coreutils programs like cp, mv, ls etc already work fine.

On 2/9/24 15:16, Lawrence D'Oliveiro wrote:
> You are referring to the wrong posting. Check what I said again.

You are apparently using Original Poster differently than everyone else
I know uses it.

Here's the References header / chain of your message:

--8<--
References: <uq1bsh$1lp15$5@dont-email.me>
<dbud9kxt1s.ln2@Telcontar.valinor>
<uq27n0$1tfdb$4@dont-email.me> <uq3jiv$25287$3@dont-email.me>
<uq3uei$tu7$7@tncsrv09.home.tnetconsulting.net>
<uq41t2$2a4jh$6@dont-email.me>
<uq48vu$4q9$2@tncsrv09.home.tnetconsulting.net>
<uq4ad1$2fjnu$3@dont-email.me>
<uq4dks$rko$2@tncsrv09.home.tnetconsulting.net>
<uq4dti$2g52k$1@dont-email.me>
<uq5jb7$okd$5@tncsrv09.home.tnetconsulting.net>
-->8--

Pay attention to "<uq1bsh$1lp15$5@dont-email.me>".

Then look at the Message-ID: header of the first message in this thread,
your message:

--8<--
From: Lawrence D'Oliveiro <ldo@nz.invalid>
Newsgroups: comp.os.linux.misc
Subject: Case-Insensitive File/Directory Names
Date: Thu, 8 Feb 2024 01:48:02 -0000 (UTC)
Message-ID: <uq1bsh$1lp15$5@dont-email.me>
Injection-Date: Thu, 8 Feb 2024 01:48:02 -0000 (UTC)

Did you know that the ext4 filesystem has the option for case-insensitive
file/directory names?
-->8--

The Natural Philosopher did say "I once mistakenly ...". But they were
not the /original/ /poster/.

--
Grant. . . .

On 9/02/24 01:52, Grant Taylor wrote:
> On 2/7/24 23:45, Lawrence D'Oliveiro wrote:
>> The first one that matches, same as now.
>
> I disagree.
>
> `su` (lower case) is decidedly not `SU` upper case.
>
> And if your system was using case insensitive files like you are
> suggesting and I arranged to put `SU` in a directory earlier in your
> path, you just ran a trojan when you mean to run `su`.
>
> This is a first hand example of why case folding is a Bad Idea (TM).
>
>
>

You are making a big deal out of the fact that if there is a trojan in
your $PATH, you might accidentally run it.

Yes.

Don't put trojans in your $PATH, no matter what they are called.

On 09/02/2024 21:20, Lawrence D'Oliveiro wrote:
> On Fri, 9 Feb 2024 10:02:58 +0000, The Natural Philosopher wrote:
>
>> On 08/02/2024 22:11, Lawrence D'Oliveiro wrote:
>>> On Thu, 8 Feb 2024 09:42:56 +0000, The Natural Philosopher wrote:
>>>
>>>> I once mistakenly added a case sensitive disk to an Apple OS/X
>>>> machine.
>>>> Applications promptly stopped working.
>>>
>>> That’s the opposite of what we’re discussing here.
>>
>> But it's the same issue, just the other way around. Either case matters
>> inside the code you are using or it doesn't. Switching that over makes
>> stuff break.
>
> If your stuff is already written to be cross-platform-compatible with
> Apple’s or Microsoft’s platforms, then it will have already dealt with
> this.
>
It wasn't. It was Quark Xpress. Back in about 2008 or thereabouts.

> If the code is written to not care whether the filesystem is case-
> sensitive or not, then it will work either way.
>
It wasn't. It was written on the assumption that case didn't matter in
filenames. When I created a filesystem where it did matter, it wouldn't run.

> Standard coreutils programs like cp, mv, ls etc already work fine.

They are linux utils.

Not OS/X per se

--
"And if the blind lead the blind, both shall fall into the ditch".

Gospel of St. Mathew 15:14

On Sat, 10 Feb 2024 01:44:48 +0000, The Natural Philosopher wrote:

> On 09/02/2024 21:20, Lawrence D'Oliveiro wrote:
>
>> Standard coreutils programs like cp, mv, ls etc already work fine.
>
> They are linux utils.

Wasn’t the argument made that there would be problems in both directions?

On 10/02/2024 02:28, Lawrence D'Oliveiro wrote:
> On Sat, 10 Feb 2024 01:44:48 +0000, The Natural Philosopher wrote:
>
>> On 09/02/2024 21:20, Lawrence D'Oliveiro wrote:
>>
>>> Standard coreutils programs like cp, mv, ls etc already work fine.
>>
>> They are linux utils.
>
> Wasn’t the argument made that there would be problems in both directions?

Probably. What has that got to do with anything?

Do you linux geeks EVER run applications that run outside the command line?

--
In a Time of Universal Deceit, Telling the Truth Is a Revolutionary Act.

- George Orwell

On 2024-02-09 22:16, Lawrence D'Oliveiro wrote:
> On Fri, 9 Feb 2024 10:19:51 -0600, Grant Taylor wrote:
>
>> On 2/8/24 23:41, Lawrence D'Oliveiro wrote:
>>
>>> Here’s what the OP said:
>>
>> No ... that's not what the OP said, nor was that the OP.
>
> You are referring to the wrong posting. Check what I said again.

There is only a single OP, which is always the parent post of the entire
thread, which is yours in this case, a post in which you explained how
to make ext4 directories case insensitive, on 2024-02-08 02:48

If the thread then diverges in other branches, the OP remains being the
same, for ever. Even if the Subject line is changed.

--
Cheers, Carlos.

On 10/02/2024 09:44, Carlos E.R. wrote:
> On 2024-02-09 22:16, Lawrence D'Oliveiro wrote:
>> On Fri, 9 Feb 2024 10:19:51 -0600, Grant Taylor wrote:
>>
>>> On 2/8/24 23:41, Lawrence D'Oliveiro wrote:
>>>
>>>> Here’s what the OP said:
>>>
>>> No ... that's not what the OP said, nor was that the OP.
>>
>> You are referring to the wrong posting. Check what I said again.
>
>
> There is only a single OP, which is always the parent post of the entire
> thread, which is yours in this case, a post in which you explained how
> to make ext4 directories case insensitive, on 2024-02-08 02:48
>
> If the thread then diverges in other branches, the OP remains being the
> same, for ever. Even if the Subject line is changed.
>
I love the smell of semantics in the morning.

--
Truth welcomes investigation because truth knows investigation will lead
to converts. It is deception that uses all the other techniques.