Keys: Export user-defined keyring operations
Subsystems (2)
A message that is not in the archive (sent off-list or not yet received): OF7208B0E9.0AB77A04-ON87257090.007A1D4E-05257090.007A2207@us.ibm.com
David Howells
maintainerPATCH 1/1 Keys: Export user-defined keyring operations
The attached patch exports user-defined key operations so that those who wish to define their own key type based on the user-defined key operations may do so (as has been requested).
The header file created has been placed into include/keys/user-type.h, thus creating a directory where other key types may also be placed. Any objections to doing this?
---
warthog>diffstat -p1 keys-userexp-2614rc3.diff
include/keys/user-type.h | 47 +++++++++++++++++++++++++++++++++++++++++ security/keys/user_defined.c | 49 +++++++++++++++++++++---------------------- 2 files changed, 71 insertions(+), 25 deletions(-)
include/keys/user-type.h +47 -0
@@ -0,0 +1,47 @@ +/* user-type.h: User-defined key type +* +* Copyright (C) 2005 Red Hat, Inc. All Rights Reserved. +* Written by David Howells ([email protected]) +* +* This program is free software; you can redistribute it and/or +* modify it under the terms of the GNU General Public License +* as published by the Free Software Foundation; either version +* 2 of the License, or (at your option) any later version. +*/ + +#ifndef _KEYS_USER_TYPE_H +#define _KEYS_USER_TYPE_H + +#include <linux/key.h> +#include <linux/rcupdate.h> + +/*****************************************************************************/ +/* +* the payload for a key of type "user" +* - once filled in and attached to a key: +* - the payload struct is invariant may not be changed, only replaced +* - the payload must be read with RCU procedures or with the key semaphore +* held +* - the payload may only be replaced with the key semaphore write-locked +* - the key's data length is the size of the actual data, not including the +* payload wrapper +*/ +struct user_key_payload { +struct rcu_head rcu;/* RCU destructor */ +unsigned short datalen;/* length of this data */ +char data[0 ];/* actual data */ +}; + +extern struct key_type key_type_user; + +extern int user_instantiate (struct key *key,const void *data,size_t datalen); +extern int user_duplicate (struct key *key,const struct key *source); +extern int user_update (struct key *key,const void *data,size_t datalen); +extern int user_match (const struct key *key,const void *criterion); +extern void user_destroy (struct key *key); +extern void user_describe (const struct key *user,struct seq_file *m); +extern long user_read (const struct key *key, +char __user *buffer,size_t buflen); + + +#endif /* _KEYS_USER_TYPE_H */
security/keys/user_defined.c +24 -25
145 lines not on this page · raw message
Quoted 7 lines · David Howells
The attached patch exports user-defined key operations so that those who wish to define their own key type based on the user-defined key operations may do so (as has been requested).
The header file created has been placed into
include/keys/user-type.h, thus creating a directory where other key types may also be placed. Any objections to doing this?
since this is new unique-to-linux functionality, could you please consider making the exports _GPL please?
David Howells
maintainerQuoted 2 lines · Arjan van de Ven
since this is new unique-to-linux functionality, could you please consider making the exports
_GPLplease?
I have.
David
Quoted 6 lines · David Howells
Quoted 2 lines · Arjan van de Ven
since this is new unique-to-linux functionality, could you please consider making the exports
_GPLplease?I have.
the patch doesn't show it though ;)
are there any users of this? Is this accidentally for an external non-GPL module??? If so sounds like a bad idea.
David Howells
maintainerQuoted 6 lines · Arjan van de Ven
Quoted 4 lines
Quoted 2 lines
since this is new unique-to-linux functionality, could you please consider making the exports
_GPLplease?I have.
the patch doesn't show it though ;)
I have considered it.
Quoted 1 line
are there any users of this?
Potentially - I've been asked for it.
Quoted 1 line
Is this accidentally for an external non-GPL module???
No.
David
Quoted 7 lines · David Howells
Quoted 5 lines · Arjan van de Ven
Quoted 4 lines
Quoted 2 lines
since this is new unique-to-linux functionality, could you please consider making the exports
_GPLplease?I have.
Quoted 7 lines
Quoted 1 line
the patch doesn't show it though ;)
I have considered it.
Quoted 1 line
are there any users of this?
Potentially - I've been asked for it.
below is the patch with _GPL exports instead, and as agreed with you with your sign-off as well
From: David Howells <[email protected]>
The attached patch exports user-defined key operations so that those who wish to define their own key type based on the user-defined key operations may do so (as has been requested).
The header file created has been placed into include/keys/user-type.h, thus creating a directory where other key types may also be placed. Any objections to doing this?
Modified to make the exports _GPL
---
warthog>diffstat -p1 keys-userexp-2614rc3.diff
include/keys/user-type.h | 47 +++++++++++++++++++++++++++++++++++++++++ security/keys/user_defined.c | 49 +++++++++++++++++++++---------------------- 2 files changed, 71 insertions(+), 25 deletions(-)
include/keys/user-type.h +47 -0
@@ -0,0 +1,47 @@ +/* user-type.h: User-defined key type +* +* Copyright (C) 2005 Red Hat, Inc. All Rights Reserved. +* Written by David Howells ([email protected]) +* +* This program is free software; you can redistribute it and/or +* modify it under the terms of the GNU General Public License +* as published by the Free Software Foundation; either version +* 2 of the License, or (at your option) any later version. +*/ + +#ifndef _KEYS_USER_TYPE_H +#define _KEYS_USER_TYPE_H + +#include <linux/key.h> +#include <linux/rcupdate.h> + +/*****************************************************************************/ +/* +* the payload for a key of type "user" +* - once filled in and attached to a key: +* - the payload struct is invariant may not be changed, only replaced +* - the payload must be read with RCU procedures or with the key semaphore +* held +* - the payload may only be replaced with the key semaphore write-locked +* - the key's data length is the size of the actual data, not including the +* payload wrapper +*/ +struct user_key_payload { +struct rcu_head rcu;/* RCU destructor */ +unsigned short datalen;/* length of this data */ +char data[0 ];/* actual data */ +}; + +extern struct key_type key_type_user; + +extern int user_instantiate (struct key *key,const void *data,size_t datalen); +extern int user_duplicate (struct key *key,const struct key *source); +extern int user_update (struct key *key,const void *data,size_t datalen); +extern int user_match (const struct key *key,const void *criterion); +extern void user_destroy (struct key *key); +extern void user_describe (const struct key *user,struct seq_file *m); +extern long user_read (const struct key *key, +char __user *buffer,size_t buflen); + + +#endif /* _KEYS_USER_TYPE_H */
security/keys/user_defined.c +24 -25
145 lines not on this page · raw message
-
Quoted 2 lines · Arjan van de Ven
since this is new unique-to-linux functionality, could you please consider making the exports
_GPLplease?
What's the point? There can be no difference between the meaning of EXPORT_SYMBOL() and EXPORT_SYMBOL_GPL() anyway.
§6 of the GPL says "You may not impose any further restrictions on the recipients' exercise of the rights granted herein."
If there was really a meaningful difference between EXPORT_SYMBOL_GPL() and EXPORT_SYMBOL(), then the GPL _itself_ would forbid the use of EXPORT_SYMBOL_GPL() within the kernel, because that would impose additional restrictions.
We should abolish the meaningless distinction between the two, because it only encourages people to believe that EXPORT_SYMBOL() can be used for non-GPL code. Either use EXPORT_SYMBOL() for everything, or switch to EXPORT_SYMBOL_GPL() for everything. It doesn't really matter.
Signature · 1 line
dwmw2
Quoted 3 lines · David Woodhouse
What's the point? There can be no difference between the meaning of
EXPORT_SYMBOL()andEXPORT_SYMBOL_GPL()anyway.
I've talked to a lawyer or two, and (a) there's an absolutely _huge_ difference and (b) they liked it.
The fact is, the law isn't a blind and mindless computer that takes what you say literally. Intent matters a LOT. And using the xxx_GPL() version to show that it's an internal interface is very meaningful indeed.
One of the lawyers said that it was a much better approach than trying to make the license explain all the details - codifying the intention in the code itself is not only more flexible, but a lot less likely to be misunderstood.
I think both them said that anybody who were to change a xyz_GPL to the non-GPL one in order to use it with a non-GPL module would almost immediately fall under the "willful infringement" thing, and that it would make it MUCH easier to get triple damages and/or injunctions, since they clearly knew about it.
I suspect programmers make horrible lawyers. They nitpick on details that sane humans don't. I think programmers often end up forgetting about the fact that human interactions don't work that way. Common sense makes a lot of difference, and DWIM is not just possible, but it's the only thing that matters.
Linus