linux-kernel - Re: [PATCH 4/9] Implement fsopen() to prepare for a mount

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]

Message-ID: <CAOssrKe-_VJ6C0Gtv0fzDW3j1QBVqPUEXPCcbFvvq13Bp1-Heg@mail.gmail.com>
Date:   Mon, 8 May 2017 17:10:07 +0200
From:   Miklos Szeredi <mszeredi@...hat.com>
To:     David Howells <dhowells@...hat.com>
Cc:     viro <viro@...iv.linux.org.uk>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        linux-nfs@...r.kernel.org, lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4/9] Implement fsopen() to prepare for a mount

On Wed, May 3, 2017 at 6:05 PM, David Howells <dhowells@...hat.com> wrote:
> Provide an fsopen() system call that starts the process of preparing to
> mount, using an fd as a context handle.  fsopen() is given the name of the
> filesystem that will be used:
>
>         int mfd = fsopen(const char *fsname, int reserved,
>                          int open_flags);
>
> where reserved should be -1 for the moment (it will be used to pass the
> namespace information in future) and open_flags can be 0 or O_CLOEXEC.

Someone also suggested using /dev/fs/${FSTYPE} to open the fsfd.  I
realize that does not have the namespace info that you also want to
add, but wondering if that really has to come from open and cannot be
set later?

Alternatives are /proc/fs/${FSTYPE}/dev or /sys/fs/${FSTYPE}/dev.

Obviously neither can be used for bootstraping but there's still old
mount(2) for that.

I haven't convinced myself whether using plain open(2) or a new
fsopen(2) syscall is better, just mentioning that this is a
possibility as well.

Thanks,
Miklos