Re: [Keyrings] Re: [PATCH 01/04] Add multi-precision-integer maths library

[Adrian Bunk <bunk@stusta.de>]

On Fri, Jan 27, 2006 at 06:35:40PM -0500, Kyle Moffett wrote:
> On Jan 27, 2006, at 17:19, Trond Myklebust wrote:
> >On Fri, 2006-01-27 at 21:41 +0100, David Härdeman wrote:
> >
> >>For example, a backup daemon which wishes to store the backup on  
> >>another host using ssh. Usually this is solved by storing an  
> >>unencrypted key in the fs or by providing a connection to a ssh- 
> >>agent which has been preloaded with the proper key(s). Both are  
> >>quite inelegant solutions.  With the in-kernel support, the daemon  
> >>can request the key using the request_key call, and (provided  
> >>proper scripts are written), the user who controls the relevant  
> >>key can supply it. This in turn means that the backup daemon can  
> >>sign using the key and read its public parts but not the private key.
> >
> >...but why would you want such a daemon to live in the kernel in  
> >the first place? A backup application might perhaps need some  
> >kernel support in order to ensure filesystem consistency, but that  
> >does not mean that moving the entire daemon into the kernel is a  
> >good idea.
> 
> No, the point is not to put the backup daemon into the kernel, but to  
> provide a way for the backup daemon and my user process to  
> communicate DSA key details without completely giving the backup  
> daemon my key.  I may not entirely trust the backup daemon not to get  
> compromised, but with support for the kernel keyring system,  
> compromising the backup daemon would only compromise the backed up  
> files, not the private keys and other secure data.

And why exactly is this not solvable through a userspace daemon?

> Cheers,
> Kyle Moffett

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed