[cap-talk] Java coding rules for capability discipline

Ian Grigg iang at systemics.com
Wed Nov 3 20:23:04 EST 2004

>> > > -- No static mutables (no class variables)
>> >
>> > How do you then guaruntee that there is only one
>> > user of a single-access resource?  For example, a
>> > manager of something like a database resource would
>> > often use a static variable to enforce its one-ness.
>> >
>> > Do you for example mean no non-private static mutables?
>> Ooops. Right. Correction, no public static mutables.
> Ooops times two (Ooooooops? :-) I was right the first time: no static
> mutables. If you allow private static mutables, then all the objects
> instantiated from a single class can still communicate with each other
> without explicit authorization, thus blowing your confinement.

Um.  I guess I want to think about that and see how
many times I really need to use static mutables...

> To ensure the following gets into the public record, let me also note
> that I made the same mistake when writing the Final DarpaBrowser Report:
> I said "no public static mutables", when I really needed to say "no
> static mutables." Some day I will get this right :-)


> Anyway, to answer your question about a single-access resource, i.e., a
> singleton object, here is an oddball idea: have a public static "make"
> method that creates and returns an object the first time it is
> called...but instead of always returning the cached created object each
> successive time, as in the typical singleton pattern, make it return a
> null every time it is called after the first time. This way you are
> guaranteed that the object is created once, and that it is moved around
> via explicit reference passing rather than by the unconfined and
> surprising (from a security perspective) backchannel of a static
> mutable.

OK, but how does the static method know to return a null
any time after the first?  It has to have some static data
available to it to know that the 2nd time has arrived, no?

Alternatively, can one do a static that is final
rather than mutable?  I must try that...  That would
solve the singleton problem, at least, in Java.

> This strategy would have a vulnerability in that, if the wrong
> guy called the make method first, the appropriate people would not get
> the object. But this would appear as an easily detected bug, not as a
> hard to find security breach (unless you're running untrusted code on
> the same jvm, in which case, you are already hosed, as noted in earlier
> email).

Yes, that would seem to be a lesser priority bug.

> Could that answer your needs? There are undoubtedly other strategies for
> making singletons in Java, but that's the one that popped into my head
> (and people with other strategies they like better are more than welcome
> to post them :-)

It's certainly all food for thought!


More information about the cap-talk mailing list