linux-kernel - Re: FS_IOC_GETFSLABEL and FS_IOC

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]

Date:   Wed, 1 Jan 2020 19:39:20 +0100
From:   Pali Rohár <pali.rohar@...il.com>
To:     "Theodore Y. Ts'o" <tytso@....edu>
Cc:     Eric Sandeen <sandeen@...hat.com>,
        Andreas Dilger <adilger@...ger.ca>,
        David Sterba <dsterba@...e.com>,
        "Darrick J. Wong" <darrick.wong@...cle.com>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: FS_IOC_GETFSLABEL and FS_IOC_SETFSLABEL

On Wednesday 01 January 2020 13:10:54 Theodore Y. Ts'o wrote:
> On Tue, Dec 31, 2019 at 04:54:18PM -0600, Eric Sandeen wrote:
> > > Because I was not able to find any documentation for it, what is format
> > > of passed buffer... null-term string? fixed-length? and in which
> > > encoding? utf-8? latin1? utf-16? or filesystem dependent?
> > 
> > It simply copies the bits from the memory location you pass in, it knows
> > nothing of encodings.
> > 
> > For the most part it's up to the filesystem's own utilities to do any
> > interpretation of the resulting bits on disk, null-terminating maximal-length
> > label strings, etc.
> 
> I'm not sure this is going to be the best API design choice.  The
> blkid library interprets the on disk format for each file syustem
> knowing what is the "native" format for that particular file system.
> This is mainly an issue only for the non-Linux file systems; for the
> Linux file system, the party line has historically been that we don't
> get involved with character encoding, but in practice, what that has
> evolved into is that userspace has standardized on UTF-8, and that's
> what we pass into the kernel from userspace by convention.
> 
> But the problem is that if the goal is to make FS_IOC_GETFSLABEL and
> FS_IOC_SETFSLABEL work without the calling program knowing what file
> system type a particular pathname happens to be, then it would be
> easist for the userspace program if it can expect that it can always
> pass in a null-terminated UTF-8 string, and get back a null-terminated
> UTF-8.  I bet that in practice, that is what most userspace programs
> are going to be do anyway, since it works that way for all other file
> system syscalls.
> 
> So for a file system which is a non-Linux-native file system, if it
> happens to store the its label using utf-16, or some other
> Windows-system-silliness, it would work a lot better if it assumed
> that it was passed in utf-8, and stored in the the Windows file system
> using whatever crazy encoding Windows wants to use.  Otherwise, why
> bother uplifting the ioctl to one which is file system independent, if
> the paramters are defined to be file system *dependent*?

Exactly. In another email I wrote that for those non-Linux-native
filesystem could be used encoding specified in iocharset= mount
parameter. I think it is better as usage of one fixing encoding (e.g.
UTF-8) if other filesystem strings are propagated to userspace in other
encoding (as specified by iocharset=).

-- 
Pali Rohár
pali.rohar@...il.com

Download attachment "signature.asc" of type "application/pgp-signature" (196 bytes)