From: Pavel Emelyanov <xemul@virtuozzo.com>
To: Oleg Nesterov <oleg@redhat.com>,
Alexey Gladkov <gladkov.alexey@gmail.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"Kirill A. Shutemov" <kirill@shutemov.name>,
Vasiliy Kulikov <segoon@openwall.com>,
Al Viro <viro@zeniv.linux.org.uk>,
"Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: [PATCH] Add pidfs filesystem
Date: Wed, 22 Feb 2017 10:40:49 +0300 [thread overview]
Message-ID: <58AD4081.9050609@virtuozzo.com> (raw)
In-Reply-To: <20170221145746.GA31914@redhat.com>
On 02/21/2017 05:57 PM, Oleg Nesterov wrote:
> On 02/18, Alexey Gladkov wrote:
>>
>> This patch allows to mount only the part of /proc related to pids
>> without rest objects. Since this is an addon to /proc, flags applied to
>> /proc have an effect on this pidfs filesystem.
>
> I leave this to you and Eric, but imo it would be nice to avoid another
> filesystem.
>
>> Why not implement it as another flag to /proc ?
>>
>> The /proc flags is stored in the pid_namespace and are global for
>> namespace. It means that if you add a flag to hide all except the pids,
>> then it will act on all mounted instances of /proc.
>
> But perhaps we can use mnt_flags? For example, lets abuse MNT_NODEV, see
> the simple patch below. Not sure it is correct/complete, just to illustrate
> the idea.
>
> With this patch you can mount proc with -onodev and it will only show
> pids/self/thread_self:
>
> # mkdir /tmp/D
> # mount -t proc -o nodev none /tmp/D
> # ls /tmp/D
> 1 11 13 15 17 19 20 22 24 28 3 31 33 4 56 7 9 thread-self
> 10 12 14 16 18 2 21 23 27 29 30 32 34 5 6 8 self
> # cat /tmp/D/meminfo
> cat: /tmp/D/meminfo: No such file or directory
> # ls /tmp/D/irq
> ls: cannot open directory /tmp/D/irq: No such file or directory
>
> No?
Yes!!! If this whole effort with pidfs and overlayfs will move forward, I would
prefer seeing the nodev procfs version, rather than another fs.
As far as the overlayfs part is concerned, having an overlayfs mounted on /proc
inside container may result in problems as applications sometimes check for /proc
containing procfs (by checking statfs.f_type == PROC_SUPER_MAGIC or by reading
the /proc/mounts).
-- Pavel
> Oleg.
>
>
> --- a/fs/proc/generic.c
> +++ b/fs/proc/generic.c
> @@ -305,11 +305,22 @@ int proc_readdir_de(struct proc_dir_entry *de, struct file *file,
>
> int proc_readdir(struct file *file, struct dir_context *ctx)
> {
> + int mnt_flags = file->f_path.mnt->mnt_flags;
> struct inode *inode = file_inode(file);
>
> + if (mnt_flags & MNT_NODEV)
> + return 1;
> +
> return proc_readdir_de(PDE(inode), file, ctx);
> }
>
> +static int proc_dir_open(struct inode *inode, struct file *file)
> +{
> + if (file->f_path.mnt->mnt_flags & MNT_NODEV)
> + return -ENOENT;
> + return 0;
> +}
> +
> /*
> * These are the generic /proc directory operations. They
> * use the in-memory "struct proc_dir_entry" tree to parse
> @@ -319,6 +330,7 @@ static const struct file_operations proc_dir_operations = {
> .llseek = generic_file_llseek,
> .read = generic_read_dir,
> .iterate_shared = proc_readdir,
> + .open = proc_dir_open,
> };
>
> /*
> --- a/fs/proc/inode.c
> +++ b/fs/proc/inode.c
> @@ -318,12 +318,16 @@ proc_reg_get_unmapped_area(struct file *file, unsigned long orig_addr,
>
> static int proc_reg_open(struct inode *inode, struct file *file)
> {
> + int mnt_flags = file->f_path.mnt->mnt_flags;
> struct proc_dir_entry *pde = PDE(inode);
> int rv = 0;
> int (*open)(struct inode *, struct file *);
> int (*release)(struct inode *, struct file *);
> struct pde_opener *pdeo;
>
> + if (mnt_flags & MNT_NODEV)
> + return -ENOENT;
> +
> /*
> * Ensure that
> * 1) PDE's ->release hook will be called no matter what
>
> .
>
next prev parent reply other threads:[~2017-02-22 7:41 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-18 22:53 [PATCH] Add pidfs filesystem Alexey Gladkov
2017-02-18 23:34 ` kbuild test robot
2017-02-18 23:34 ` kbuild test robot
2017-02-20 4:05 ` Eric W. Biederman
2017-02-20 10:36 ` Alexey Gladkov
2017-02-22 20:11 ` Richard Weinberger
2017-02-21 14:57 ` Oleg Nesterov
2017-02-22 7:40 ` Pavel Emelyanov [this message]
2017-02-22 12:04 ` Alexey Gladkov
2017-02-22 13:08 ` Pavel Emelyanov
2017-02-22 11:53 ` Alexey Gladkov
2017-02-22 15:37 ` Dmitry V. Levin
2017-02-22 17:48 ` Oleg Nesterov
2017-02-22 19:56 ` Alexey Gladkov
2017-03-06 23:05 ` [RFC] Add option to mount only a pids subset Alexey Gladkov
2017-03-07 16:24 ` Andy Lutomirski
2017-03-09 11:26 ` Djalal Harouni
2017-03-09 20:52 ` Eric W. Biederman
2017-03-11 21:51 ` Alexey Gladkov
2017-03-11 0:05 ` Alexey Gladkov
2017-03-07 17:49 ` Oleg Nesterov
2017-03-10 23:46 ` Alexey Gladkov
2017-03-12 1:54 ` Al Viro
2017-03-12 2:13 ` Al Viro
2017-03-13 3:19 ` Andy Lutomirski
2017-03-13 13:27 ` Al Viro
2017-03-13 15:24 ` Andy Lutomirski
2017-03-23 15:59 ` [PATCH] proc: allow to change proc mount options per mount Djalal Harouni
2017-03-20 12:58 ` [RFC] Add option to mount only a pids subset Alexey Gladkov
2017-03-23 16:05 ` Oleg Nesterov
2017-03-23 22:57 ` Alexey Gladkov
2017-03-23 16:06 ` Djalal Harouni
2017-03-23 22:07 ` Alexey Gladkov
2017-03-26 7:03 ` Djalal Harouni
2017-03-30 21:45 ` Alexey Gladkov
2017-02-27 18:56 ` [PATCH] Add pidfs filesystem Michael Kerrisk
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=58AD4081.9050609@virtuozzo.com \
--to=xemul@virtuozzo.com \
--cc=ebiederm@xmission.com \
--cc=gladkov.alexey@gmail.com \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=segoon@openwall.com \
--cc=viro@zeniv.linux.org.uk \
/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 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).