All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Landley <rob@landley.net>
To: Roberto Sassu <roberto.sassu@huawei.com>, viro@zeniv.linux.org.uk
Cc: linux-fsdevel@vger.kernel.org, linux-integrity@vger.kernel.org,
	linux-security-module@vger.kernel.org, initramfs@vger.kernel.org,
	linux-kernel@vger.kernel.org, zohar@linux.ibm.com,
	silviu.vlasceanu@huawei.com, dmitry.kasatkin@huawei.com,
	takondra@cisco.com, kamensky@cisco.com, hpa@zytor.com,
	arnd@arndb.de, james.w.mcmechan@gmail.com
Subject: Re: [RFC][PATCH] fs: set xattrs in initramfs from regular files
Date: Mon, 26 Nov 2018 11:42:17 -0600	[thread overview]
Message-ID: <79a41125-0232-6f6e-6f38-f4c45a7b439e@landley.net> (raw)
In-Reply-To: <b907b5ca-1515-1ed4-d50d-28c1736c0eb8@huawei.com>

On 11/26/18 6:56 AM, Roberto Sassu wrote:
> On 11/23/2018 9:21 PM, Rob Landley wrote:
>>> The aim of this patch is to provide the same functionality without
>>> introducing a new format. The value of xattrs is placed in regular files
>>> having the same file name as the files xattrs are added to, plus a
>>> separator and the xattr name (<filename>.xattr-<xattr name>).
>>
>> I think you're solving the wrong problem, but that's just my opinion.
> 
> Instead of iterating over rootfs, would it be better to detect files
> with extended attributes (from the file name) when the cpio image is
> parsed by the kernel,

Huh, I thought at first glance that's what the new approach _was_ doing.

In band signaling in the archive is ugly, still requires new tools to create it,
doesn't address the y2038 issue... (Although we could cheat, treat the time
signature as unsigned, and buy another few decades.)

But doing that in the filesystem _after_ you extract the archive is beyond ugly.

> and call sys_lsetxattr() in do_copy()? This part
> can be turned on by introducing a new type in the existing format (if
> possible).
> 
> The impact of this alternative is very low, and LSMs/IMA would be able,
> with minimum effort, to enforce policies on files in the initial ram
> disk.

The cpio extension isn't a big deal, I was pondering doing it myself in toybox
(and submitting a kernel patch to consume the output) before Mimi approached me.
(I did the initmpfs stuff already, I've stomped around in this area before.) I
just didn't because mimi sent their patch first, so I waited for that to work
its way though.

Unfortunately, it's simple enough that there was a bit of bikeshedding. (You can
store time in milliseconds as a 64 bit number without worrying about the range,
but if you do it as nanoseconds you need two fields, but people spoke up and
said "but if you don't store the nanoseconds the rounding causes spurious time
differences when between filesystems and it confuses our build system about what
has and hasn't changed"...)

The new in-band signaling proposal is, at best, a hack. (Filename lengths are
capped at 255 in the VFS, can you strip the xattrs on a long filename by having
the extension fail to create in the filesystem? Or do you have an arbitrary max
length on filenames because you need to reserve room for the extension?)

Rob

  parent reply	other threads:[~2018-11-26 17:42 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-22 15:49 [RFC][PATCH] fs: set xattrs in initramfs from regular files Roberto Sassu
2018-11-22 15:49 ` Roberto Sassu
2018-11-23 19:03 ` Casey Schaufler
2018-11-23 19:03   ` Casey Schaufler
2018-11-23 19:30   ` Mimi Zohar
2018-11-24  2:07     ` Casey Schaufler
2018-11-26 12:51       ` Mimi Zohar
2018-11-26 16:17         ` Casey Schaufler
2018-11-23 20:21 ` Rob Landley
2018-11-26 12:56   ` Roberto Sassu
2018-11-26 12:56     ` Roberto Sassu
2018-11-26 16:34     ` Casey Schaufler
2018-11-26 17:42     ` Rob Landley [this message]
2018-11-26 18:14       ` Roberto Sassu
2018-11-26 18:14         ` Roberto Sassu

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=79a41125-0232-6f6e-6f38-f4c45a7b439e@landley.net \
    --to=rob@landley.net \
    --cc=arnd@arndb.de \
    --cc=dmitry.kasatkin@huawei.com \
    --cc=hpa@zytor.com \
    --cc=initramfs@vger.kernel.org \
    --cc=james.w.mcmechan@gmail.com \
    --cc=kamensky@cisco.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=roberto.sassu@huawei.com \
    --cc=silviu.vlasceanu@huawei.com \
    --cc=takondra@cisco.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=zohar@linux.ibm.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.