won't warn neither prevent usage of « risky » characters in labels

Status changed to 'Confirmed' because the bug affects multiple users.

hi , same things .
More , it is possible [b]without[/b] escaping any special characters in the gparted application .
For example , i can give a new label to an ext partition entering : /DATA/é*/$ ( in gparted ) .

In order for e2label to modify the file system label, you need to have write access to the block device. That means that a malicious user can always directly modify the blockdevice (or just use a version of e2label that doesn't have the proposed check). Hence, this feature request should not be considered a security feature. This seems to be more of a "protect a naive / clueless user who tries to set a file system label: 'Make money fa$t".

« Hence, this feature request should not be considered a security feature »

Nobody said it was a security feature.

But I surely think it's inappropriate that an utility allows to create « flawed » labels.

Flawed by what definition? Editors allow people to create files with spaces, or with dollar signs, or with accepted characters. Some of these characters may require quoting if you use spaces or doll=lars. Not allowing accented characters will cause speakers of various European languages to complain that you're not letting them use french words in file names (or file system labels), and this is an unacceptable English language hegemony over the great languange which is French. :-)

In fact, there's nothing wrong with using any of these characters in file system labels. For example, look at /dev/disk/by-label for a filesystem set with "e2label /tmp/foo.img foo\$bar":

# ls /dev/disk/by-label/
total 0
ext-disk 'foo\x24bar' lambda-backup old-files@
           ^^^^^^^^^^^^
And with the filename label set via "e2label /tmp/foo.img Misère"

# /bin/ls /dev/disk/by-label
ext-disk lambda-backup Misère old-files
                         ^^^^^^^

So how are these characters flawed? what makes them be forced to wear a large scarlet letter "A" over their clothing? Why shouldn't the french be allowed to use accepted characters in file names or in file system labels?

Inquiring minds want to know.... but as the upstream maintainer of e2fsprogs, I absolutely reject this as a bug.

You misread the case here, Theodore.
It's not a problem of language - accented letters and diacritics are used in many languages and might be used in labels.

Sorry for me just being a stupid downstream user. Such names with « special » characters in are a flawed design as they have high potential for confusion ( both for human and system. )

As in your example

foo\$bar → becomes → 'foo\x24bar' → not exactly the same form, which might not be expected by uneducated user. And ( legitimately ) escaped but not usable « as is » in all context.

In fact, there's nothing wrong with using any of these characters in file system labels.

Of course, there's something wrong about using *some* of those characters / \ space * $ #
Accented letters are not the issue ( except with new Ubuntu installer… )

What will be the output of

cd /path/to/{ any label containing / or * or $ or spaces in its name }

if { label name } is not escaped ?

To prevent user from any later confusion, e2label should at least gives a warning if « special » characters are used inside a label.

And my opinion is that e2label should strictly prevent using those « special » characters inside label.
While those can be « managed » with escaping, « names » in paths should never create confusion, so avoiding by default / or $ or * sound safer to me.

Right, but exactly the same argument can be made about disallowing anything other than plain ASCII characters in file names. It may be that in some graphical interfaces, spaces and accented characters and special characters like "$" don't require any escaping whatsoever. In other command-line interfaces, they require escaping. Shall we not allow spaces when saving OpenOffice filenames because when you look at the using the command line interface, you need to type something like:

/media/arena/Music/Coig/Carols/01\ Carol\ of\ the\ Celts.mp3

Sure, this might be "confusing to the uneducated user", but just go ahead and file a bug against RipperX claiming that all such filenames should prohibited. I'll wait, and see what you get back from the author....

If we are going to restrict labels and filenames to least common denominators, then we can't allow any special characters, because the "uneducated user" might not know how to type "è" on a US keyboard. Where do we draw the line in terms of enforcing policy to protect the "uneducated user" from themselves?

A warning if « special » characters are used in labels might be a first step in the right direction.

Once again accented letters and diacritics are not the problem here
but characters that might get « translated » as « functions » such as / \ * and few others.

Only those.

Space character is rather well managed by auto-completion in most CLI. Mostly.

It's not least common denominator but only the few characters that could be « risky ».
All other characters remain possible.

And it's not only about « uneducated user », it's just safer for everyone by making labels more robust and « foolproof ».

But hey am just the stupid user ( sheep ) and you are the upstream maintainer ( god ).
You could make e2label smarter but you can't make users smarter after all…
So be it ?

Your original bug request said: "e2label lets you use any character, including / or * or $ ( and probably others, like accented letters é è à )..... it should not be possible to use those in label names." You've now backpedaled and said, "I never said that! Only "risky" characters!"

"Risky" as defined by whom? In your example, lsblk and e2label displayed the label without a problem. Who cares if you needed to use a backslash to protect the "$" or "*" or " " characters? They look just fine. And if the argument is that space character is well managed by auto-completion in most CLI "mostly", I'll note that so is the "*" character. For example:

% touch qfoo\*bar
% ls qf<tab>

... and bash will expand that to "qfoo\*bar" so it works just **fine** with bash. I've just checked and the completion function used in ksh, tcsh, and emacs (which does not require any quoting so that's a gimme) means that it works just fine. So any argument that you use for outlawing * in labels would apply to spaces, too ---- and if for labels, why not filenames? Shouldn't filenames be "robust" and "foolproof"? By some unknown definition of "fool"?

Going back to labels ---- for the most part, labels are mostly used for display purposes, so if someone happens to create a label with a ' ', '*', or '$' character, it's not a big deal; lsblk, blkid, etc. will display them just fine. And no escaping is necessary if you put a special character in /etc/fstab. For example, the following works in /etc/fstab:

LABEL=foo$bar /mnt ext4 defaults 0 0

Sure, some care might be needed to *set* the label to "foo$bar" --- you might need to type "e2label /dev/loop0 'foo$bar'" --- but the quoting rules are enforced by the shell. It might be some other shell might not use "$" for variables --- or there might be a disk management GUI which doesn't use quoting, just as emacs and Libreoffice doesn't require quoting for file names with spaces in it. So setting some arbitrary rule because of the interface that the user might be using doesn't make any sense. If the user is smart enough to figure out how to pass 'foo$bar' to e2label, we should let them use it. Why should we print some kind of nanny-state, "naughty, naughty! you did something that might confuse a less clueful user!!" warning.

Again, the standard that said we should do that for labels would also apply to characters, and then I will have *other* launchpad users complaining to me about why did I set some kind of arbitrary restriction, and that they had a perfectly good reason for wanting to use these characters in their label or their filenames.

Ok, ok, amen, so be it.

If it's ok in fstab, if bash always expands correctly then you're right, don't change anything if it would bring more annoyance than ease of life.

Title is « won't warn neither prevent usage of « risky » characters in labels »
Nothing else.

Accented letters in partition label seem ( nowadays ) a problem with latest Ubuntu installer - as reported by geole on the forum ( am just quoting here as I was unable to do anything with the latest Ubuntu installer by my side, so can't confirm myself. )

No backpedaling from me - your bad reading because you jumped on accented letters while I always was worrying about the « special / risky » characters and insisted twice on that matter.

« Why should we print some kind of nanny-state, "naughty, naughty! you did something that might confuse a less clueful user!!" warning »
Because that's how you catch attention on a topic and eventually teach someone how to do better, for self and others.

Anyway thank you for your answers and explanations which justify why e2label needs no change.
Labels can't be an issue if I understand correctly.

( oot : foolproof is the first translation I've found for « à toute épreuve » ; bulletproof ? )