Linux-Fsdevel Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Johannes Thumshirn <Johannes.Thumshirn@wdc.com>
To: "dsterba@suse.cz" <dsterba@suse.cz>, Johannes Thumshirn <jth@kernel.org>
Cc: "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
Eric Biggers <ebiggers@google.com>,
Richard Weinberger <richard@nod.at>,
Johannes Thumshirn <jthumshirn@suse.de>
Subject: Re: [PATCH v3 2/3] btrfs: add authentication support
Date: Wed, 27 May 2020 13:54:51 +0000 [thread overview]
Message-ID: <SN4PR0401MB3598593BC0AF9909CC1986889BB10@SN4PR0401MB3598.namprd04.prod.outlook.com> (raw)
In-Reply-To: <20200527132428.GE18421@twin.jikos.cz>
On 27/05/2020 15:25, David Sterba wrote:
> On Thu, May 14, 2020 at 11:24:14AM +0200, Johannes Thumshirn wrote:
>> From: Johannes Thumshirn <johannes.thumshirn@wdc.com>
>> Example usage:
>> Create a file-system with authentication key 0123456
>> mkfs.btrfs --csum "hmac(sha256)" --auth-key 0123456 /dev/disk
>>
>> Add the key to the kernel's keyring as keyid 'btrfs:foo'
>> keyctl add logon btrfs:foo 0123456 @u
>>
>> Mount the fs using the 'btrfs:foo' key
>> mount -o auth_key=btrfs:foo,auth_hash_name="hmac(sha256)" /dev/disk /mnt/point
>
> I tried to follow the example but the filesystem does not mount. But
> what almost shocked me was the way the key is specified on the userspace
> side.
>
> $ mkfs.btrfs --csum "hmac(sha256)" --auth-key 0123456 /dev/disk
>
> "0123456" are the raw bytes of the key? Seriously?
>
> And how it's passed to the hmac code:
>
> gcry_mac_hd_t mac;
> gcry_mac_open(&mac, GCRY_MAC_HMAC_SHA256, 0, NULL);
> gcry_mac_setkey(mac, fs_info->auth_key, strlen(fs_info->auth_key));
> gcry_mac_write(mac, buf, length);
> gcry_mac_read(mac, out, &length);
>
> Strlen means the key must avoid char 0 and I don't think we want do any
> decoding from ascii-hex format, when there's the whole keyctl
> infrastructure.
>
> The key for all userspace commands needs to be specified the same way as
> for kernel, ie. "--auth-key btrfs:foo" and use the appropriate ioctls to
> read the key bytes.
>
Hohum?
Here's what I just did:
rapido1:/# keyctl add logon btrfs:foo 0123456 @u
1020349071
rapido1:/# mkfs.btrfs --csum "hmac(sha256)" --auth-key 0123456 /dev/zram1
btrfs-progs v5.6
See http://btrfs.wiki.kernel.org for more information.
Detected a SSD, turning off metadata duplication. Mkfs with -m dup if you want to force metadata duplication.
Label: (null)
UUID: 56ae43ac-f333-4ed4-933a-356aed534115
[ 31.005743] BTRFS: device fsid 56ae43ac-f333-4ed4-933a-356aed534115 devid 1 transid 5 /dev/zram1 scanned by mkfs.btrfs (241)
Sector size: 4096
Filesystem size: 3.00GiB
Block group profiles:
Data: single 8.00MiB
Metadata: single 8.00MiB
System: single 4.00MiB
SSD detected: yes
Incompat features: extref, skinny-metadata
Checksum: hmac-sha256
Number of devices: 1
Devices:
ID SIZE PATH
1 3.00GiB /dev/zram1
rapido1:/# mount -o auth_key=btrfs:foo,auth_hash_name="hmac(sha256)" /dev/zram1 /mnt/
[ 65.959465] BTRFS info (device (efault)): doing authentication
[ 65.963204] BTRFS info (device zram1): disk space caching is enabled
[ 65.964137] BTRFS info (device zram1): has skinny extents
[ 65.964912] BTRFS info (device zram1): flagging fs with big metadata feature
[ 65.968302] BTRFS info (device zram1): enabling ssd optimizations
[ 65.969551] BTRFS info (device zram1): checking UUID tree
rapido1:/#
next prev parent reply other threads:[~2020-05-27 13:54 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-14 9:24 [PATCH v3 0/3] Add file-system authentication to BTRFS Johannes Thumshirn
2020-05-14 9:24 ` [PATCH v3 1/3] btrfs: rename btrfs_parse_device_options back to btrfs_parse_early_options Johannes Thumshirn
2020-05-14 9:24 ` [PATCH v3 2/3] btrfs: add authentication support Johannes Thumshirn
2020-05-27 13:24 ` David Sterba
2020-05-27 13:54 ` Johannes Thumshirn [this message]
2020-05-27 14:01 ` Johannes Thumshirn
2020-05-27 18:04 ` Johannes Thumshirn
2020-06-01 14:30 ` David Sterba
2020-06-01 14:35 ` David Sterba
2020-05-14 9:24 ` [PATCH v3 3/3] btrfs: document btrfs authentication Johannes Thumshirn
2020-05-14 12:26 ` Jonathan Corbet
2020-05-14 14:54 ` Johannes Thumshirn
2020-05-14 15:14 ` Richard Weinberger
2020-05-14 16:00 ` Jonathan Corbet
2020-05-14 16:05 ` Richard Weinberger
2020-05-24 19:55 ` David Sterba
2020-05-25 10:57 ` Johannes Thumshirn
2020-05-25 11:26 ` David Sterba
2020-05-25 11:44 ` Johannes Thumshirn
2020-05-25 13:10 ` [PATCH v3 0/3] Add file-system authentication to BTRFS David Sterba
2020-05-26 7:50 ` Johannes Thumshirn
2020-05-26 11:53 ` David Sterba
2020-05-26 12:44 ` Johannes Thumshirn
2020-06-01 14:59 ` David Sterba
2020-05-27 2:08 ` Qu Wenruo
2020-05-27 11:27 ` David Sterba
2020-05-27 11:58 ` Qu Wenruo
2020-05-27 13:11 ` David Sterba
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=SN4PR0401MB3598593BC0AF9909CC1986889BB10@SN4PR0401MB3598.namprd04.prod.outlook.com \
--to=johannes.thumshirn@wdc.com \
--cc=dsterba@suse.cz \
--cc=ebiggers@google.com \
--cc=jth@kernel.org \
--cc=jthumshirn@suse.de \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=richard@nod.at \
--subject='Re: [PATCH v3 2/3] btrfs: add authentication support' \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).