Re: file metadata via fs API (was: [GIT PULL] Filesystem Information)

From: Casey Schaufler <casey@schaufler-ca.com>
To: Andy Lutomirski <luto@amacapital.net>,
	Linus Torvalds <torvalds@linux-foundation.org>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	David Howells <dhowells@redhat.com>,
	Al Viro <viro@zeniv.linux.org.uk>, Karel Zak <kzak@redhat.com>,
	Jeff Layton <jlayton@redhat.com>,
	Miklos Szeredi <mszeredi@redhat.com>,
	Nicolas Dichtel <nicolas.dichtel@6wind.com>,
	Christian Brauner <christian@brauner.io>,
	Lennart Poettering <lennart@poettering.net>,
	Linux API <linux-api@vger.kernel.org>,
	Ian Kent <raven@themaw.net>,
	LSM <linux-security-module@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Casey Schaufler <casey@schaufler-ca.com>
Subject: Re: file metadata via fs API (was: [GIT PULL] Filesystem Information)
Date: Tue, 11 Aug 2020 09:17:39 -0700	[thread overview]
Message-ID: <a6cd01ed-918a-0ed7-aa87-0585db7b6852@schaufler-ca.com> (raw)
In-Reply-To: <5C8E0FA8-274E-4B56-9B5A-88E768D01F3A@amacapital.net>

On 8/11/2020 8:39 AM, Andy Lutomirski wrote:
>
>> On Aug 11, 2020, at 8:20 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>>
>> [ I missed the beginning of this discussion, so maybe this was already
>> suggested ]
>>
>>> On Tue, Aug 11, 2020 at 6:54 AM Miklos Szeredi <miklos@szeredi.hu> wrote:
>>>
>>>> E.g.
>>>>  openat(AT_FDCWD, "foo/bar//mnt/info", O_RDONLY | O_ALT);
>>> Proof of concept patch and test program below.
>> I don't think this works for the reasons Al says, but a slight
>> modification might.
>>
>> IOW, if you do something more along the lines of
>>
>>       fd = open(""foo/bar", O_PATH);
>>       metadatafd = openat(fd, "metadataname", O_ALT);
>>
>> it might be workable.
>>
>> So you couldn't do it with _one_ pathname, because that is always
>> fundamentally going to hit pathname lookup rules.
>>
>> But if you start a new path lookup with new rules, that's fine.
>>
>> This is what I think xattrs should always have done, because they are
>> broken garbage.
>>
>> In fact, if we do it right, I think we could have "getxattr()" be 100%
>> equivalent to (modulo all the error handling that this doesn't do, of
>> course):
>>
>>  ssize_t getxattr(const char *path, const char *name,
>>                        void *value, size_t size)
>>  {known
>>     int fd, attrfd;
>>
>>     fd = open(path, O_PATH);
>>     attrfd = openat(fd, name, O_ALT);
>>     close(fd);
>>     read(attrfd, value, size);
>>     close(attrfd);
>>  }
>>
>> and you'd still use getxattr() and friends as a shorthand (and for
>> POSIX compatibility), but internally in the kernel we'd have a
>> interface around that "xattrs are just file handles" model.

This doesn't work so well for setxattr(), which we want to be atomic.

> This is a lot like a less nutty version of NTFS streams, whereas the /// idea is kind of like an extra-nutty version of NTFS streams.
>
> I am personally not a fan of the in-band signaling implications of overloading /.  For example, there is plenty of code out there that thinks that (a + “/“ + b) concatenates paths. With /// overloaded, this stops being true.

Since a////////b has known meaning, and lots of applications
play loose with '/', its really dangerous to treat the string as
special. We only get away with '.' and '..' because their behavior
was defined before many of y'all were born. 