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  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, 12 Aug 2020 16:10:56 +0200
From:   Miklos Szeredi <>
To:     David Howells <>
Cc:     Linus Torvalds <>,
        linux-fsdevel <>,
        Al Viro <>, Karel Zak <>,
        Jeff Layton <>,
        Miklos Szeredi <>,
        Nicolas Dichtel <>,
        Christian Brauner <>,
        Lennart Poettering <>,
        Linux API <>,
        Ian Kent <>,
        LSM <>,
        Linux Kernel Mailing List <>
Subject: Re: file metadata via fs API (was: [GIT PULL] Filesystem Information)

On Wed, Aug 12, 2020 at 3:54 PM David Howells <> wrote:
> Linus Torvalds <> wrote:
> > 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.
> What is it going to walk through?  You need to end up with an inode and dentry
> from somewhere.
> It sounds like this would have to open up a procfs-like magic filesystem, and
> walk into it.  But how would that actually work?  Would you create a new
> superblock each time you do this, labelled with the starting object (say the
> dentry for "foo/bar" in this case), and then walk from the root?
> An alternative, maybe, could be to make a new dentry type, say, and include it
> in the superblock of the object being queried - and let the filesystems deal
> with it.  That would mean that non-dir dentries would then have virtual
> children.  You could then even use this to implement resource forks...
> Another alternative would be to note O_ALT and then skip pathwalk entirely,
> but just use the name as a key to the attribute, creating an anonfd to read
> it.  But then why use openat() at all?  You could instead do:
>         metadatafd = openmeta(fd, "metadataname");
> and save the page flag.  You could even merge the two opens and do:
>         metadatafd = openmeta("foo/bar", "metadataname");
> Why not even combine this with Miklos's readfile() idea:
>         readmeta(AT_FDCWD, "foo/bar", "metadataname", buf, sizeof(buf));

And writemeta() and createmeta() and readdirmeta() and ...

The point is that generic operations already exist and no need to add
new, specialized ones to access metadata.


Powered by blists - more mailing lists