* [PATCH 2/3] eCryptfs: export key type
@ 2005-06-02 5:48 Phillip Hellewell
2005-06-03 20:03 ` Michael Halcrow
0 siblings, 1 reply; 5+ messages in thread
From: Phillip Hellewell @ 2005-06-02 5:48 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 203 bytes --]
This is the second in a series of three patches for the eCryptfs kernel
module.
The key_type_user symbol in user_defined.c needs to be exported.
--
Phillip Hellewell <phillip AT hellewell.homeip.net>
[-- Attachment #2: patch-2.6.12-rc4-mm2-ecryptfs-2_of_3-export-key-type.diff --]
[-- Type: text/plain, Size: 523 bytes --]
diff -Naur linux-2.6.12-rc4-mm2/security/keys/user_defined.c linux-2.6.12-rc4-mm2-ecryptfs/security/keys/user_defined.c
--- linux-2.6.12-rc4-mm2/security/keys/user_defined.c 2005-05-23 21:20:38.252134304 -0600
+++ linux-2.6.12-rc4-mm2-ecryptfs/security/keys/user_defined.c 2005-05-23 21:38:04.092142456 -0600
@@ -48,6 +48,8 @@
char data[0]; /* actual data */
};
+EXPORT_SYMBOL( key_type_user );
+
/*****************************************************************************/
/*
* instantiate a user defined key
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 2/3] eCryptfs: export key type
2005-06-02 5:48 [PATCH 2/3] eCryptfs: export key type Phillip Hellewell
@ 2005-06-03 20:03 ` Michael Halcrow
2005-06-06 9:42 ` David Howells
0 siblings, 1 reply; 5+ messages in thread
From: Michael Halcrow @ 2005-06-03 20:03 UTC (permalink / raw)
To: Phillip Hellewell; +Cc: linux-kernel, David Howells
On Wed, Jun 01, 2005 at 11:48:52PM -0600, Phillip Hellewell wrote:
> This is the second in a series of three patches for the eCryptfs
> kernel module.
>
> The key_type_user symbol in user_defined.c needs to be exported.
> ...
> +EXPORT_SYMBOL( key_type_user );
This is the only modification necessary to support eCryptfs. While we
are working on getting it ready for merging into the mainline kernel,
we would like to distribute it as a separate kernel module, and we
would like for users or distro's do not need to modify their kernels
to build and run it.
Would there be any objections to exporting the key_type_user symbol?
Is there any general reason why kernel modules should not have access
to the user key type struct?
Mike
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 2/3] eCryptfs: export key type
2005-06-03 20:03 ` Michael Halcrow
@ 2005-06-06 9:42 ` David Howells
2005-06-06 18:42 ` [PATCH 2/3, 2.6.12-rc5-mm1] eCryptfs: export user " Michael Halcrow
0 siblings, 1 reply; 5+ messages in thread
From: David Howells @ 2005-06-06 9:42 UTC (permalink / raw)
To: Michael Halcrow; +Cc: Phillip Hellewell, linux-kernel
Michael Halcrow <mhalcrow@us.ibm.com> wrote:
> > +EXPORT_SYMBOL( key_type_user );
>
> This is the only modification necessary to support eCryptfs.
Unfortunately, that might have to be EXPORT_SYMBOL_GPL() nowadays since I
reimplemented the predefined keyring types of user and keyring using RCU.
> While we are working on getting it ready for merging into the mainline
> kernel, we would like to distribute it as a separate kernel module, and we
> would like for users or distro's do not need to modify their kernels to
> build and run it.
"It" being?
> Would there be any objections to exporting the key_type_user symbol?
> Is there any general reason why kernel modules should not have access
> to the user key type struct?
No and no, but see above. You could also export the user defined key type ops
and define your own key type using them.
David
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 2/3, 2.6.12-rc5-mm1] eCryptfs: export user key type
2005-06-06 9:42 ` David Howells
@ 2005-06-06 18:42 ` Michael Halcrow
2005-06-07 9:52 ` David Howells
0 siblings, 1 reply; 5+ messages in thread
From: Michael Halcrow @ 2005-06-06 18:42 UTC (permalink / raw)
To: Andrew Morton; +Cc: Phillip Hellewell, linux-kernel, David Howells
On Mon, Jun 06, 2005 at 10:42:02AM +0100, David Howells wrote:
> Michael Halcrow <mhalcrow@us.ibm.com> wrote:
> > > +EXPORT_SYMBOL( key_type_user );
> >
> > This is the only modification necessary to support eCryptfs.
>
> Unfortunately, that might have to be EXPORT_SYMBOL_GPL() nowadays
> since I reimplemented the predefined keyring types of user and
> keyring using RCU.
Noted; new patch included below.
> > While we are working on getting it ready for merging into the
> > mainline kernel, we would like to distribute it as a separate
> > kernel module, and we would like for users or distro's do not need
> > to modify their kernels to build and run it.
>
> "It" being?
eCryptfs.
> > Would there be any objections to exporting the key_type_user
> > symbol? Is there any general reason why kernel modules should not
> > have access to the user key type struct?
>
> No and no, but see above. You could also export the user defined key
> type ops and define your own key type using them.
I can imagine scenarios where new kernel modules make use some
universal key type (i.e., without userspace apps having to be aware of
a special keytype). The ``user'' key type seems like a good candidate
for that.
Signed off by: Michael Halcrow <mhalcrow@us.ibm.com>
--- linux-2.6.12-rc5-mm1/security/keys/user_defined.c 2005-05-28 17:18:52.000000000 -0500
+++ linux-2.6.12-rc5-mm1-ecryptfs/security/keys/user_defined.c 2005-06-06 13:26:58.757403080 -0500
@@ -48,6 +48,8 @@
char data[0]; /* actual data */
};
+EXPORT_SYMBOL_GPL(key_type_user);
+
/*****************************************************************************/
/*
* instantiate a user defined key
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2005-06-07 9:52 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-06-02 5:48 [PATCH 2/3] eCryptfs: export key type Phillip Hellewell
2005-06-03 20:03 ` Michael Halcrow
2005-06-06 9:42 ` David Howells
2005-06-06 18:42 ` [PATCH 2/3, 2.6.12-rc5-mm1] eCryptfs: export user " Michael Halcrow
2005-06-07 9:52 ` David Howells
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox