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:   Sat, 28 Dec 2019 12:14:57 -0700
From:   Andreas Dilger <adilger@...ger.ca>
To:     Pali Rohár <pali.rohar@...il.com>
Cc:     Eric Sandeen <sandeen@...hat.com>, 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 Dec 28, 2019, at 7:36 AM, Pali Rohár <pali.rohar@...il.com> wrote:
> 
> Hello!
> 
> I see that you have introduced in commit 62750d0 two new IOCTLs for
> filesyetems: FS_IOC_GETFSLABEL and FS_IOC_SETFSLABEL.
> 
> I would like to ask, are these two new ioctls mean to be generic way for
> userspace to get or set fs label independently of which filesystem is
> used? Or are they only for btrfs?
> 
> 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 seems that SETFSLABEL is supported by BtrFS and XFS, and GETFSLABEL
also by GFS2.  We were just discussing recently about adding it to ext4,
so if you wanted to submit a patch for that it would be welcome.

It looks like the label is a NUL-terminated string, up to the length
allowed by the various filesystems.  That said, it seems like a bit of
a bug that the kernel will return -EFAULT if a string shorter than the
maximum size is supplied (256 chars for btrfs).

The copy_{to,from}_user() function will (I think) return the number of
bytes remaining to be copied, so IMHO it would make sense that this is
compared to the string length of the label, and not return -EFAULT if
the buffer is large enough to hold the actual label.  Otherwise, the
caller has to magically know the maximum label size that is returned
from any filesystem and/or allocate specific buffer sizes for different
filesystem types, which makes it not very useful as a generic interface.

Cheers, Andreas

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