warlord at MIT.EDU
Thu Nov 6 21:19:23 CST 2003
Let me think about this and get back to you. At a first
approximation, the "user" should have some "user authentication
context", and ALL engine APIs should require (either explicitly or
implicitly) that context and verify the user's permission to perform
Whether the underlying architecture is role-based, capability-based,
or ACL-based can be decided later. The important point is that every
API function need to check the context for permission to perform the
operation -- which requires each API to have access to the user
linas at linas.org (Linas Vepstas) writes:
> Um, Derek, Since I'm busy tearing things up with qof anyway,
> this might be a good time to discuss this. Do you have any
> particular opinions or good ideas on how to accomplish priveldge
> separation, etc. ? Would you want a capabilites system?
> Something with ACL's/MAC-like thingy? Hooks for both? Users?
> All I'm thinking of would be to add appripriate hooks to
> appropriate places, and 'refactor' as needed, and add the bare-bones
> minimal to keep it working as it currently does. But I haven't
> given this design much thought, so now is a good time to point
> out any of the 'fundamental design flaw' type issues, and possible
> blue-sky workarounds for them.
> Let me know ...
> pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas at linas.org>
> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord at MIT.EDU PGP key available
More information about the gnucash-user