linux-kernel - Re: [PATCH 36/38] vfs: Add a sample program for the new mount API [ver #10]

lists.openwall.net		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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+55aFzpisX0+T_ipwUdOCXY+tkhe2Ao3KDZxx+UPpguVmirnQ@mail.gmail.com>
Date:   Mon, 30 Jul 2018 11:59:13 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     Pavel Machek <pavel@....cz>, David Howells <dhowells@...hat.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 36/38] vfs: Add a sample program for the new mount API
 [ver #10]

On Mon, Jul 30, 2018 at 11:38 AM Matthew Wilcox <willy@...radead.org> wrote:
>
> I wasn't proposing putting gettext in the kernel.  I was reacting to
> Pavel saying "You can't return English strings from the kernel, you have
> to translate numbers into any language's strings".

The problem with gettext() is that if you *don't* have the strings
marked for translated at the source, you're going to have a hard time
with anything but the simplest fixed strings.

When the kernel does something like

     mntinfo("Option %s can not take value %d", opt->name, opt->value);

a gettext() interface inside the kernel (which really would be nasty)
would have seen the format string and the values independently and
would have generated the translation database from that.

But once the string has been generated, it can now be thousands of
different strings, and you can't just look them up from a table any
more.

Real examples from David's patch-series:

                errorf(fc, "%s: Lookup failure for '%s'",
                       desc->name, param->key);

                errorf(fc, "%s: Non-blockdev passed to '%s'",
                       desc->name, param->key);

which means that by the time user space sees it, you can't just "look
up the string". The string will have various random key names etc in
it.

But the alternative to pass things as format strings and raw data, and
having all the rules for a "good gettext interface" are worse. It gets
very ugly very quickly.

So I really think the best option is "Ignore the problem". The system
calls will still continue to report the basic error numbers (EINVAL
etc), and the extended error strings will be just that: extended error
strings. Ignore them if you can't understand them.

That said, people have wanted these kinds of extended error
descriptors forever, and the reason we haven't added them is that it
generally is more pain than it is necessarily worth. I'm not actually
at all convinced that has magically changed with the mount
configuration thing.

             Linus