[racktables-users] Re: user ACL how to
- From: Denis Ovsienko <pilot@xxxxxxxxxx>
- To: racktables-users@xxxxxxxxxxxxx
- Date: Sat, 21 Jun 2008 22:39:08 +0400
> I've been having a look at the userPermission table and I'm having
> troubles about what the expected format for "page" and "tab" fields
> is. On the other hand, I'm not clear if the page/tab approach makes
> so much sense. I see the need for a general "read only" and "read
> and write" ACL and then some granular high level one (probably
> attached to the "tag" concept), so the user-cases become more or less
> like:
That's exactly what is happening in the SVN trunk to denote the start of
0.16.x releases. Let me show a couple of examples.
> * Some people (some global admin) has read-write access to everything
Old (UserPermission, 0.15.1 and all previous releases) notation:
username = admin
page = % // any page
tab = % // any tab
access = yes
New (RackCode, 0.16.0 and following release) notation:
allow {$userid_1} // admin is always UID 1 regardless of username
Both schemes deny access by default and both consists of a single
"administrator can do anything" rule in the freshly-installed system.
An automatic conversion is performed and is supposed to be correct,
but this is yet a work in progress.
> * Some people (maybe some manager) has read-only access to everything
Old style:
username = manager
page = % // any page
tab = default // all "read-only" tabs are named "default"
access = yes
New style:
allow {$username_manager} and {$tab_default}
Alternatively, if you have many managers and a "Manager" tag, that flags
all of them, you can issue a more generic permission instead of
repeating the above rule for each of them:
allow {Manager} and {$tab_default}
> * Some people (maybe some client) has read-only access to their own
> assets (say, all the objects at whatever location, maybe a rack and
> its contents)
Old style: not available
New style: first tag their stuff with something descriptive. Then issue
a single rule:
allow {$username_johndoe} and {$tab_default} and {John Doe asset}
> * Some people (maybe some delegated sysadmin) has read-write access
> to some delegated assets (maybe location-based, "our sysadmin at
> Colorado Springs", maybe kind-of-object-based, "our network guru with
> access to all routers").
Again, the key to success is a proper tagging. You might have several
hierarchies: one for geographical location, another for people
hierarchy or competence level. After tagging assets, users and resources
properly the permission rules can look quite trivial. On the other
hand, there's no limit how complex they are, cause they are
interpreted. You can always fine-grain the permission plan even further.
E.g., let's have the follwing tag tree:
- assets
-- HQ assets
-- HQ managed
-- Arizona assets
-- Texas assets
- admins
-- HQ admins
-- Arizona admins
-- Texas admins
Then the following ruleset would allow each branch viewing all,
but managing only own assets. Some local stuff could be placed under
authority of the headquarters (this stuff would be tagged with 2 tags
at a time).
allow {admins} and {assets} and {$tab_default}
deny not {HQ admins} and {HQ managed}
allow {Arizona admins} and {Arizona assets}
allow {Texas admins} and {Texas assets}
allow {HQ admins} and ({HQ assets} or {HQ managed})
The rules are evaluated top-down, first match wins instantly.
> A second, only partially related question: I think your code has some
> hard dependencies on php5, but it's all procedural even when at least
> some places seem to be crying for OOP (the auth code, for instance).
> Is there any reason not to use classes that I should be aware of?
Well, the 5th version of PHP seems to be the best common ground among
different OSes and distributions, it is the choice for its extensions,
not the OO option. Object-oriented versus procedural approach is sooner
a matter of taste for such small codebases, as we have. Your vision may
vary, of course.
--
DO4-UANIC
Other related posts:
