netdev - [RFC] connectat() and bindat() system calls

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

Date:	Wed, 6 Jun 2012 12:38:51 +0400
From:	Stanislav Kinsbursky <skinsbursky@...allels.com>
To:	<linux-fsdevel@...r.kernel.org>,
	"davem@...emloft.net" <davem@...emloft.net>
CC:	<cgroups@...r.kernel.org>, <containers@...ts.linux-foundation.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>,
	"Trond.Myklebust@...app.com" <Trond.Myklebust@...app.com>,
	"bfields@...ldses.org" <bfields@...ldses.org>,
	James Bottomley <jbottomley@...allels.com>,
	"devel@...nvz.org" <devel@...nvz.org>
Subject: [RFC] connectat() and bindat() system calls

Hello.
I'd really appreciate for any comments on subj - implementation of new system 
call: connectat and bindat.

Reasons for new system calls:
1) Path length for UNIX sockets is limited to 108 symbols.
Syscalls are useful as is since removes limitation.

2) Ability to perform connect/bind calls to UNIX sockets starting from specified 
path in kernel.
This is required for proper support of kernel connect operations in SUNRPC 
layer. Which, in turn, required for proper support of NFS in containers.

These system calls could be used only for non-abstract UNIX sockets, obviously.

Possible implementation could be adding of struct path pointer to sockaddr_un.
But this pointer have to valid only for connect and bind calls, and caller have 
to hold and release path by himself.

-- 
Best regards,
Stanislav Kinsbursky
--
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