linux-kernel - Re: [PATCH] autofs: show pipe inode in mount options

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1452257913.7030.25.camel@themaw.net>
Date:	Fri, 08 Jan 2016 20:58:33 +0800
From:	Ian Kent <raven@...maw.net>
To:	skinsbursky@...tuozzo.com
Cc:	criu@...nvz.org, autofs@...r.kernel.org,
	linux-kernel@...r.kernel.org, Al Viro <viro@...IV.linux.org.uk>
Subject: Re: [PATCH] autofs: show pipe inode in mount options

On Fri, 2016-01-08 at 12:29 +0100, Stanislav Kinsburskiy wrote:
> 
> 08.01.2016 08:20, Ian Kent пишет:
> > On Thu, 2016-01-07 at 16:46 +0100, Stanislav Kinsburskiy wrote:
> > > Good day, gentlemen.
> > > 
> > > Could you update, what's the status with this patch?
> > > Without it it's impossible to match process pipe with kernel
> > > pipe,
> > > while
> > > this is "must have" to be able to migrate AutoFS via CRIU.
> > Right, I did mean to reply to this mail but have been distracted by
> > family stuff.
> > 
> > I don't know what CRIU is and people looking at changelog entries
> > shouldn't need to do a web search to find out.
> > 
> > Could you change it a little.
> 
> Fair enough. I'll resend with more descriptive message.
> But first I would like to clarify to you the problem root and why
> it's 
> done like this.
> 
> > I'm also not sure whether to forward this (assuming the description
> > is
> > updated a little) to Al or to include it in the series to rename
> > autofs4 to autofs that I'm hoping to ask be included in linux-next
> > fairly soon.
> 
> Here I don't know, what's better. Of course Al can take it as well.
> But, 
> probably, first would be nice to make sure, that this solution is the
> best one.
> Description of the problem is below.
> 
> > Passing it on to Al will likely interfere with the series coming
> > from
> > linux-next so that could be bit of a hassle.
> > 
> > Another thing I'm wondering about is the order this entry will
> > appear
> > at in the options. You order choice is sensible though and autofs
> > shouldn't have a problem with the inserted option but other
> > applications might.
> 
> I should put it at the end, probably?
> 
> > Finally, and perhaps most importantly, I don't get what your trying
> > to
> > do, you also haven't given any clues to that in the patch
> > dscription.
> > 
> > IOW how do you expect to use this.
> > 
> > > 
> > > 16.12.2015 13:02, Stanislav Kinsburskiy пишет:
> > > > This is required for CRIU to migrate a mount point, when write
> > > > end
> > > > in user
> > > > space is closed.
> > Like I said what does this mean.
> > 
> > autofs doesn't need this when it re-constructs a mount tree from
> > existing mounts on re-start or after a SIGKILL on the automount
> > process.
> > 
> > How is this different and how will it be used?
> > 
> > The question to be answered here is "is this the best way to do it
> > and
> > will it work for the autofs mount types you expect it to"?
> 
> So, here is a brief description of the problem.
> To migrate autofs mount, one have to reconstruct control pipe between
> kernel and autofs master.
> There are two cases I'm wiling to support:
> 1) Automount binary (autofs package). This program is very gentle and
> it 
> doesn't close write end of the pipe after mount.
> 2) Systemd. This program closes write end of the pipe once the mount
> is 
> done.

I must admit I'm having trouble understanding the description.
Give me a little time with it.

I don't know how systemd works with autofs mounts only that it uses the
autofs direct mount type.

autofs uses both indirect and direct mounts and both can have offsets
(from the kernel POV semantically direct mounts). So there is quite a
bit to worry about beside the kernel pipe.

Anyway, it seems your only concern is the kernel pipe and I wonder why
you can't just set the mount catatonic (in autofs speak) on save and
open a new kernel pipe then set the pipefd on the autofs mount on
restore.

But probably my suggestion is far to simplistic as I get the impression
you have a process already in a given state which you want to restore.

One thing to keep in mind is that if an autofs mount is not set
catatonic any access other than the owner process (process group pid)
will hang unless there is an actual user space process to service the
callback.

Although I don't know the flow of things that might be important at
some point.

And if the mount is set catatonic the process needs to set the pipefd
to take "ownership" which also clears the mount catatonic flag.

Anyway, let me think about what you've written for a while.
Ian