How to prevent very very large ccaches?

[Nicolas Williams]

On Tue, Jun 18, 2002 at 06:55:25PM -0400, Ken Raeburn wrote:
> So add it. :-)
> 
> Whether we want to add it to the advertised API (such as it is) may be
> a different question, but certainly having the functionality available
> within the library is fine.

The thought did cross my mind. But I thought first I might like to
understand why there was no such function in the first place.

BTW, it would, in fact, be dangerous for app code to unset the OPENCLOSE
flag. Think of a daemon doing some ccache stuff at startup then
daemonizing and, in the process, indiscriminately closing all open file
descriptors; this happens. So either the danger would have to be
advertised in the docs or defensive code would be needed to check that
the ccache fd stashed in the ccache struct is still valid (probably by
doing a stat() and comparing its results to cached stat data).

So you see why I did not add a new API. Nor did I think a new internal
API was absolutely necessary because it was sufficiently clear to me from
the source that the OPENCLOSE flag would always be set when retrieving
creds from a ccache.

> Yes, I think in the long run this is probably the better choice, and
> probably by way of the CCAPI interface.  I wasn't that serious about
> db, it's a lot to add in just for a little gain in ccache performance.

I really need to go understand just what CCAPI is all about.

> Another thing to look at in the short term would be the stdio version
> of the ccache code.  Since it uses buffering, it wouldn't make nearly
> as many i/o calls.  Currently it's turned on by using "STDIO:" instead
> of "FILE:", but really I think it should be an implementation detail
> which one of the two is used for "FILE:" since AFAIK the contents
> should be the same regardless of the means used to access the disk
> file.

Indeed. Though the fix I posted would still be needed - otherwise you'd
see the same open/lock/lseek/read/close behaviour as with FILE, only
with fewer read()s; it's the locking that is the problem, and besides,
with stdio there'd be little gain due to I/O buffering if the file were
opened and closed for each ccache entry sequenced!

> Ken

Cheers,

Nico
-- 
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.