Handling of private/confidential groupware objects
bernhard at intevation.de
Wed Jan 25 12:37:25 CET 2006
Am Montag, 23. Januar 2006 23:29 schrieb Martin Konold:
> Am Montag, 23. Januar 2006 09:58 schrieb Bernhard Reiter:
> > This cannot be guarenteed as long as clients can set the ACL
> > of all the folders. A user _could_ set the ACL of the hidden folder
> > differently. Or do you think that we should add more protection
> > to the imapd implementation then?
> Well, if users shoot themself in the foot we cannot prevent them from doing
> so in the good old unix tradition. Though we could apply "self healing"
> semantics to the Kolab clients which can "fix" the wrong ACLs.
> IMHO trying to prevent intentional shooting the foot will in the end
> require TPM like architectures.
well this is a general type argument which can be used in any direction.
We are discussing the how to make a good solution which is easy
enough to understand and use so that people will not shoot them
in their feet.
My question was to find out how you would propose to handle the case
that user can set ACLs on the "hidden" folders.
You are saying: We do not handle this case,
which means we cannot guarantee that a hidden folder is "private"
to the ower of the folder in all cases on the server, it depends on the ACL
of the hidden folder.
> I don't think we want to go this route and therefore don't buy your
> argument why my proposal is either impractical or insecure.
This question was is one aspect,
and yes it is an aspect against your proposal.
However this always needs to be weighted with all aspects.
I have not disregarded your proposal yet,
but with my current knowledge, I think
the other solution is better.
More information about the format