[cap-talk] Singleton discussion (was: Re: object-oriented-security.org)

[Ben Kloosterman]

I do . nothing is immutable with regards to maintenance and they are still
global scope I once had to change some configuration from a readonly
singleton to dynamic and it was a royal pain  references were everywhere.
AFAIK the only thing mutability on singletons affects is multi threading.
Going by our analogy is a open on a readonly file good ?

If that read-only file has exactly the same contents on every system in the
world, and those contents never change, then it's OK.  In any other case, it
can't really be considered a constant.

 

In that case some executables never change . I don't think anyone is
suggesting you would NOT need capabilities on an executable that never
changes ..Something is wrong either the singleton for constant data or the
file system analogy. 

 

And as I stated I worked on a project where we constants like AU , m etc
Which you would not expect to change but there was a requirement to change
all configuration to be dynamic so the old config module got scrapped and I
had to pull static constant references from a huge amount of code due to
their global scope.  Which meant all those statics are a pain.  While data
may be constant at runtime with regard to maintenance nothing is constant .

 

 good use of a singleton is as a Fascade to wrap more complex structures and
to allow cross module communication. But it should be infrequent eg it would
be ok  to get a reference to the Filesystem interface/API through a
singleton. But once you have your reference use instance calls .

No, this is not OK, for many reasons which have been repeated several times
now:

- It means code using this singleton only works with the "real" filesystem,
not any other filesystem that the caller of your code might want you to work
with.

Not really as the Singleton just holds a file system object that may be
changed eg via a config file

 

- It means code using this singleton is hard to test, because any test has
to modify the "real" filesystem instead of simply providing your code with a
mock.

 

.  It does means it's a bit  hard to test but it is only a Fascade for an
internal OO structure its not an issue.

 

- Most importantly to this mailing list, it means that any piece of code is
able to get access to the filesystem, which is insecure.

 

That's is true .. But it does not mean they have access to any files..
Accessing a file system but not having access to a file is not an issue. In
this case its more likely it would be the VFS root. Which would return a
file system instance which you could pass capabilities into.

 

Static Fascades are a well excepted pattern used in many (most ?) libs to
make them easier  to use the key is to  use them just for a few frequently
used entry points after all every program has a static entry provided by a
lib . main(). 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20100313/f203a670/attachment.html