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  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:	Thu, 19 Nov 2015 18:25:33 -0800
From:	Maciej ┼╗enczykowski <zenczykowski@...il.com>
To:	Tom Herbert <tom@...bertland.com>
Cc:	Lorenzo Colitti <lorenzo@...gle.com>,
	Eric Dumazet <eric.dumazet@...il.com>,
	David Miller <davem@...emloft.net>,
	Hannes Frederic Sowa <hannes@...essinduktion.org>,
	Stephen Hemminger <stephen@...workplumber.org>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	Eric Dumazet <edumazet@...gle.com>, Erik Kline <ek@...gle.com>,
	Dmitry Torokhov <dtor@...gle.com>
Subject: Re: Add a SOCK_DESTROY operation to close sockets from userspace

> No, I mean something that kills connections where previously this did
> not happen. The fact that this is done at the process level does not
> justify that it is a right to at do connections. Besides, if you
> really intend to do this then provide a privileged process a means to
> close *any* open file descriptor in the system (why stop at TCP
> sockets)!

There is little reason to be able to kill random processes arbitrary
file descriptors,
while there is ample reason to be able to kill network connections.

Network connections can already (and often are) be killed by the network, but
that's far less true for files (although IO errors and emergency fs remount r/o
can cause similar behaviour).

Userspace doesn't expect file descriptors to local files to suddenly break,
while it already has to handle network connections timing out and the like.

Perhaps we shouldn't be using the word 'kill'.  We're not really killing
these sockets, nor closing them, we just need an out-of-band mechanism
for flagging them with some sort of error (ie. force timing them out, or force
resetting them).

That said, one can certainly come up with cases where killing arbitrary file
descriptors would make sense (or more likely switching them from r/w to r/o
mode or replacing them with some sort of /dev/null like file
descriptor instead).
Example use cases would be umounting a removable usb key which is in the
process of being pulled out of the machine (or was already pulled
out), or remounting
a file system readonly (which still has r/w open files).
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists