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]
Message-ID: <25410.1174054546@redhat.com>
Date:	Fri, 16 Mar 2007 14:15:46 +0000
From:	David Howells <dhowells@...hat.com>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	davem@...emloft.net, netdev@...r.kernel.org, herbert.xu@...hat.com,
	linux-kernel@...r.kernel.org, arjan@...radead.org
Subject: Re: [PATCH 4/5] AF_RXRPC: Key facility changes for AF_RXRPC [try #2] 

Christoph Hellwig <hch@...radead.org> wrote:

> You wrote the code so there must be some reason for this, but these
> changes look rather odd to me :)

The union is for use by the type in any way it sees fit, but it may not want to
use it as a list_head.  So all I've done is to make it available as a pair of
arbitrary pointers or a pair of arbitrary numbers.

Maybe a better way would be to have an overlay struct that's private to the
type, sort of how sk_buff::cb works.

> Having a type exported is really odd, how is this supposed to be a public API?

Keyrings are a special type.

It occurred to me whilst doing this that the best way to achieve what I wanted
was by dealing with rings of keys.  What I needed was for the server app to
give the kernel a key for each security type it wanted to support, which the
kernel would then have to retain.  It seems natural to use a keyring to do the
retension as that's its purpose.

Another way to look at it is that in the client I need just one key at once,
and I can get that from the process as it's setting up the connection.
However, in the server I need to have several keys, and I need them available
up front because the server app doesn't set up a connection, the kernel does,
and it needs the keys immediately.

I'll add a mention to Documentation/keys.txt to record this exportation.

David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ