Re: Wishlist: credential file update/access collision avoidance?

[email protected]
Newsgroups gmane.comp.encryption.kerberos.heimdal.general
Message-ID <[email protected]>
Hi Roland,

On Mon, Oct 03, 2011 at 12:16:49AM +0100, Roland C. Dowdeswell wrote:
> > file system, not all of them are posix. Of course such file systems are
> > rarely used for ccaches but you never know. (Note that nothing actually
> > prevents a ccache from being shared between computers.)
> 
> Well, I would say that it is completely reasonable to say that
> ccaches will not correctly operate on file systems that do not
> conform to the POSIX specifications because ccaches are local
> credentials which should not be stored on distributed file systems.

Depending on what is considered to be a "correct operation" it
may be true or not. For my purposes it would work very well to share
credentials between my processes on several computers of the same security
domain. A protected shared file system would be ok (why not?), even a
distributed one - if it provides strong authentication, authorization and
confidentiality which e.g. Coda does.

In general, ccaches are not "local credentials", their contents is to be
used in a distributed context. The local credential of a process in Unix
is its uid (and gid and possibly some more things but you get the idea).

So I can not agree with your statement.

> Also, if compatibility with non-POSIX file systems is desired, then
> specific implementations will have to be named such that they can
> be tested against.  After all, saying ``a filesystem that does not
> conform with POSIX'' without naming a specific implementation is
> more or less meaningless.  What exactly does it mean for a file
> system to break a few rules?  Which rules?

Exactly, to be able to rely on a file system we need to specify
which properties must be present. It can not break any rules until we
formulated them. (Or did we? I may have missed the relevant paragraph
in the documentation, then sorry).

> Generally, in these sorts of discussions, the examples would be
> distributed file systems such as NFS, AFS, etc.  But, these file
> systems pose different problems and frequently code will have to
> have specific work-arounds for them.  And, in the case of ccaches
> and keytabs, distributed file systems probably should not be used.

As long as there is no formal description of how the file system is
expected to behave, nor a formal description of how the ccache files are
to be accessed and updated, it is actually broken for local file systems
as well as for distributed ones. An implementation is not a specification.

So I do not suggest putting ccaches on distributed file systems as a
default, this should be done with great care, but nothing says
that it is impossible, never useful or inherently insecure.

On the other side I an unhappy with the state of specification and
documentation around ccaches. Different people apparently have different
views on the semantics and there is hardly a certainty about what a
developer thinks when (s)he writes Kerberos-related code. Not good for
security in the code, nor for secure practices at deployment.

Regards,
Rune
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.