I’m designing a system, and it needs future expandability for the use of a permission system of some kind. I’m wondering if the flyweight pattern would be a good choice to implement this. I’m not responsible for the implementation right now, as it is just a prototype, and we’re not prototyping any parts that need the right system. However, because of the demand for future extensibility to parts that need permission management the interface needs to be solid. This means that in the end it will be a thought experiment, rather than a real part of what I have to work on. However, I do need to be able to explain and justify my design in this area of the application.
In favour of using the are that you can define permissions by having them symbolized through a token class, as represented in the flyweight pattern. If you’re dealing with hundreds of users, this would somewhat simplify the handling and issuing of the rights a user holds, and the required rights a user needs for an action within the system; as well as the memory usage of the rights assigned to all the users.
In the system I have in mind, a factory method of some kind will assign the rights needed at construction time.
As I’m not really experienced with designing with security in mind, I’m having a paranoid line of thought of which I can’t determine if it’s justified, security wise. A shared pointer could be hijacked by ‘evil intruders’ to gain rights they should not be getting. This is the major argument against the use of a flyweight that keeps bugging me, Even though the ‘how’ is undefined, and I wouldn’t know how someone would get it done. (no experience in the security mindset, or it’s workings. However, I’m not really looking for a lecture in security beyond the secure use of patterns, unless motivated and clearly related to the question)
Q: Is the flyweight pattern a suitable pattern to manage the representation of the rights of a user (or other some ‘hand out’ type of data) in the design of a software system that needs to be secure by design? Does the use of flyweight objects as representation of permissions pose more of a security risk than other patterns (I could also use a decorator chain for it, even though that would take up more memory) when dealing with permissions?
0
If you’re trying to design the interface, why are you worrying about the implementation details? Even on the level of making an implementation, I think worrying about whether to use flyweight is premature. Flyweight is a memory-space optimization, and if you don’t know how much space you’re using to start with, how do you know it will save you space?
You don’t mention what kinds of things you’ll be tracking with the permissions, so I’ll assume that it’s about the same amount as unix-style read/write/execute bits for user, group, and other. That’s a total of 9 bits; depending on how you slice it, it will fit in 2 or 3 bytes. Each flyweight would need a pointer, probably in the range 32-64 bits, or 4 to 8 bytes. So, even if you didn’t need to allocate any more space for the permission objects (and you would), you’re probably increasing memory requirements.
Of course, that might not be true if your permissions objects are large enough, but in that case, you’d still get nothing from flyweight unless there was a significant amount of duplication in your large objects. Do you know that you would get a lot of duplication among your objects and that they’d be relatively large? Probably not, if you’re still figuring out the interface.
I can’t really tell you about security, but it seems to me that if anyone has penetrated your system to the point that they can overwrite an arbitrary pointer, they already have control over your program.
4