linux-kernel - Re: [PATCH 0/2] fs/lock: show locks info owned by dead/invisible processes

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]

Date:   Fri, 8 Jun 2018 19:02:35 +0300
From:   Cyrill Gorcunov <gorcunov@...tuozzo.com>
To:     Konstantin Khorenko <khorenko@...tuozzo.com>
Cc:     Andrey Vagin <avagin@...tuozzo.com>,
        Benjamin Coddington <bcodding@...hat.com>,
        Jeff Layton <jlayton@...nel.org>,
        "J. Bruce Fields" <bfields@...ldses.org>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Vasily Averin <vvs@...tuozzo.com>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] fs/lock: show locks info owned by dead/invisible
 processes

On Fri, Jun 08, 2018 at 05:27:10PM +0300, Konstantin Khorenko wrote:
> The behavior has been changed after 9d5b86ac13c5 ("fs/locks: Remove fl_nspid
> and use fs-specific l_pid for remote locks")
> and now /proc/$PID/fdinfo/$FD does not show the info about the lock
> * if the flock owner process is dead and its pid has been already freed
> or
> * if the lock owner is not visible in current pidns.
> 
> CRIU uses this interface to store locks info during dump and thus can break
> on v4.13 and newer.

Indeed, it should cause problems with procfs parsing. We should add a test
for such scenarions, and since we're running tests by linux-next all the time
we would have this issue catched already.

The series looks ok to me, but I'm not flock expert so better wait for more
trustworthy opinion.

> 
> So let's show info about locks anyway in described cases (like it was before
> 9d5b86ac13c5), but show pid number saved in file_lock struct if we are in
> init_pid_ns (patch 1) or just zero otherwise (patch 2) like we do with SID.