netdev - Re: [PATCH 0/9] use network namespace for iSCSI control interfaces

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] [day] [month] [year] [list]

Message-ID: <20171121202033.GC13246@straylight.hirudinean.org>
Date:   Tue, 21 Nov 2017 12:20:33 -0800
From:   Chris Leech <cleech@...hat.com>
To:     David Laight <David.Laight@...LAB.COM>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "containers@...ts.linux-foundation.org" 
        <containers@...ts.linux-foundation.org>
Subject: Re: [PATCH 0/9] use network namespace for iSCSI control interfaces

On Tue, Nov 21, 2017 at 11:26:09AM +0000, David Laight wrote:
> From: Chris Leech
> > Sent: 15 November 2017 00:25
> > To: David Laight
> > Cc: netdev@...r.kernel.org; containers@...ts.linux-foundation.org
> > Subject: Re: [PATCH 0/9] use network namespace for iSCSI control interfaces
> > 
> > On Wed, Nov 08, 2017 at 10:31:04AM +0000, David Laight wrote:
> > > From: Chris Leech
> > > > Sent: 07 November 2017 22:45
> > > >
> > > > I've posted these changes to allow iSCSI management within a container
> > > > using a network namespace to the SCSI and Open-iSCSI lists, but seeing
> > > > as it's not really SCSI/block related I'm casting a wider net looking
> > > > for reviews.
> > >
> > > I didn't spot you acquiring and releasing references to the namespace.
> > > (I might have missed it, the relevant patch is difficult to read).
> > >
> > > If the sockets are created in the context of the process whose namespace
> > > you are using you don't need it, but given the hooks and callbacks
> > > I'm not at all sure that is obviously true.
> > 
> > Thanks David,
> > 
> > Looking at it again, you're right and I think I need to hold a reference
> > for the iSCSI host and handle namespace deletion.  Even for iscsi_tcp
> > the socket gets handed off from the creating process to the transport
> > and can outlive iscsid.
> 
> It isn't that simple....
> IIRC:
> 
> The namespace delete callback isn't made until the reference count is zero.
> Sockets created with sock_create_kern() don't hold a reference to the
> namespace
> 
> This is all fine for sockets used for admin purposes, but rather hopeless
> if you really need the namespace to continue to exist while the connections
> are open - if only for long enough to close the connection.

Yeah, I'm catching up on a lot of the details as I attempt to sort out
what a sane behavior for iscsi_tcp should be here.

With these patches as is, iscsi_tcp will hold a reference to a TCP
socket created by iscsid and keep the net namespace from exiting.
That's good for keeping iSCSI sessions alive.  Bad in that all processes
attached to the namespace can terminate, and if filesystem references
(like bind mounts from ip-netns) are unlinked then I don't see any way
to get back into the namespace to shut down iSCSI.

I've been trying to sort out a way to shut down and clean up in that
case, but the other approach might be to look at having a kernel thread
to reference the namespace so that the ns inode could be recovered from
/proc?
 
> To make matters even more annoying the functions for holding and
> releasing a namespace are GPL_ONLY :-(

I have no problem with that.

Thanks,
Chris Leech