linux-kernel - Re: [RFC 0/3] fs,epoll: Add ability to call kcmp to find target files

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: <39a65773-a58e-032b-1448-5e03bf78d763@akamai.com>
Date:   Tue, 21 Feb 2017 15:32:21 -0500
From:   Jason Baron <jbaron@...mai.com>
To:     Cyrill Gorcunov <gorcunov@...nvz.org>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-api@...r.kernel.org
Cc:     viro@...iv.linux.org.uk, akpm@...uxfoundation.org,
        avagin@...tuozzo.com, xemul@...tuozzo.com, mtk.manpages@...il.com,
        kir@...nvz.org, luto@...capital.net
Subject: Re: [RFC 0/3] fs,epoll: Add ability to call kcmp to find target files

On 02/21/2017 11:59 AM, Cyrill Gorcunov wrote:
> Hi! In previous series EPOLL_CTL_DUP operation has been discussed
> but considered as potentially scary. So here is an another approach:
>
>  - extend fdinfo of epoll files with inode, device and file position
>    for every target, which allow the reader to gather targets with
>    this bundle as a key for primary sorting
>
>  - extent kcmp to check if some particular file is matching one
>    sitting inside epoll queue (duplicate numbers are resolved with
>    offset parameter)
>

Hi,

Since an epoll fd can be added to another epoll fd, I'm wondering if you 
have enough data here to figure that out. The inode is the 
'anon_inode_inode', so I'm wondering if that is sufficient to 
distinguish it from other anonymous inodes, or if an extra bit is 
required to indicate if the target file is in fact and epoll fd.

Thanks,

-Jason

> Please take a look once time permit. Note that I did only basic
> testing (without CRIU) but it should fit our needs because we
> sort and lookup regualr files by same scheme. So I'm about to
> implemet full criu support for this new kernel features in
> a couple of days thus any comments are *higly* appreciated.
>
> NB: Initially I added
>
> 	if (file_ns_capable(epi->ffd.file, ns, CAP_SYS_ADMIN))
>
> into fdinfo output to check if caller is allowed to see
> target ino/dev/pos but dropped it later because if process
> is added file descriptor into epoll queue it mean fdstat
> and such already can be called and this information is
> already obtained, so I don't this it's information
> disclosure.
>
> 	Cyrill
>