Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Solo (3889)

Solo
  (email not shown publicly)
http://mghicks.wordpress.com/

Journal of Solo (3889)

Thursday November 10, 2005
07:41 PM

UC4, Perl and TT2

At my day job, we use an enterprise job scheduler called UC4. I don't have experience with its competition to make comparisons, but UC4 itself has a frustrating scripting language built in. It lacks true loop constructs, has only basic expression handling (one operation at a time), and so on. I suppose we'll make a complete list of annoyances one day. For now, I'm more interested in workarounds than vendor developments.

One thing that UC4 got right is an XML-based import/export mechanism. Any object (except folders, which are purely organizational) can be exported, modified and imported. Savvy users can even create XML files from scratch and import them, but it's much more practical to edit export files IMO.

One of my major annoyances with UC4 is how difficult it is to handle the same job or job plan for multiple systems. Solution: Perl and TT2. I can embed TT2 directives in my UC4 objects, export them to XML, process the XML with perl, TT2 and a datafile, import to UC4 and generate the same object for multiple systems. Viola!

I needed to use START_TAG and END_TAG that UC4 could accomodate, '#$' and '#@' respectively (UC4 has rules about what an object can be named), but apart from that, the processing script was very simple--basically identical to the Template::Plugin::Datafile module. I had a working system in about 15 minutes, once I'd thought of it.

Is anyone else using UC4 for their job scheduling and feeling the same? I'd post some code and example objects to Perlmonks, but I wonder the audience is too small.

Monday November 15, 2004
04:06 PM

Three months later I climbed out of the basement

It started with learning Nagios. The middle act was a nasty flu bug. The last bit was leaky plumbing in the basement. I once heard that time seems to go by faster as you age because each new day is a smaller percentage of your overall experience. Three months went pretty quick this time.

Somewhere along the line I picked up the Mod_Perl Cookbook. Good read, but now behind the Apache 2 curve.

That book put my finger on one frustration I have with embedded Perl Nagios (ePN). There's no mod_perl-ish perl-status equivalent in ePN. It seems impossible to know basic things like how many and which scripts are loaded and running in ePN, which modules and versions are loaded, etc. I think I'll try to roll my own with Devel::SymDump.

Saturday August 28, 2004
09:44 PM

New manager

My new cross-continent manager has been in town, and that's meant more meetings and less time. So, falling behind on everything else Perl. :/

As part of the (resurgence of) globalization at work we are moving from Big Brother to Nagios. The version of Nagios in use is "2.0a1" with embedded Perl. Gah! Only available in CVS and still in dev! Anyways, my little experience with mod_perl has been getting me by. It's always nice to look like you know what you're doing in front of the new manager. ;p

Thursday August 19, 2004
03:09 PM

Rate a module a day on cpanratings.perl.org

I posed a question sort of related to this thought at Perlmonks, but this space is my little soapbox, so I'm gonna step on it.

I pledge to rate at least one module I use each day on CPAN Ratings! (Until I have rated all the modules I use.)

I challenge everyone else to do the same.

I don't pledge that I will have anything insightful to say about the module, and I wouldn't have a review text at all except that it's a required field. But I will rate the module 1 - 5 on a combination of how I 'feel' about it, how easy it was for me to use and how helpful I found it.

Why? Because a statistically relevant sampling of the modules in use, and a comparison of which are more used, is just as important as insightful reviews of modules. Seeing 5 stars with 2 ratings is less meaningful than 4 stars with 50 ratings.

Whether you dismiss this as 'popularity', it doesn't make the measurement unimportant. Things that are popular are popular for a reason. Things that are widely used have larger support bases (an important consideration in the opensource arena.) Companies and employers like statistics that back decisions.

But for that kind of data to even exist, more people need to rate the modules they use, whether or not they have a useful review of the modules.

If we don't want to use cpanratings.perl.org this way, it should be called 'CPAN Reviews'.

Update: diotalevi has requested comments on his submit-cpan-ratings script that aims to facilitate more ratings and reviews.

Wednesday August 18, 2004
02:06 PM

Authorization and Permissions

Recently, I've been dealing with authorization issues in applications. I'm beginning to wonder whether or not a 'general-purpose' Authz module could be created. This is not a finished idea.

Basically everyone understands Authentication and Authorization are different concerns. But, of those concerns, Authentication receives almost all of the coverage. Compare the number of *authen* to *authz* modules on the CPAN. Authorization modules tend to be part of application distributions as well, and not modules for general-use.

Does the lack of modules represent a lack of interest or need, or an inability to generalize all the bits surrounding authorization?

Since many people don't exactly agree on definitions*, I'll make my ideas clear. Authorization is the run-time process for determining whether an actor may take action on an object under present conditions and allowing or denying the action. Permissions are the data used in the determination. I call the combination of actor, object acted upon, and conditions context.

Based on these definitions, the first half of authorization can be thought of as a boolean function of action, context and permissions.

boolean authorized( action, context, permissions )

This function is the determination part of authorization. Allowing or denying is the other half.

if ( authorized( action, context, permissions ) ) {
    allow action
}
else {
    deny action
}

That's a pretty general framework for authorization.

Action is somewhat dependent on the system or application, but there are some common actions that almost always require authorization.

Create   Making new things
Read     Looking at things
Update   Changing existing things
Delete   Removing or destroying things
Execute  Using things

Context includes actor, object and conditions. They are pretty self-explanatory, I'll just mention that actor can be anything authenticated (a person or another program or computer) and object doesn't imply OO, but rather, a thing. Condition represents additional factors that might be important to authorization. Date and time are typical 'condition' examples.

Permissions are a persisted set of actions and contexts that are either allowed or disallowed.

Consider some common examples of how authorization is implemented.

  • Apache's .htaccess files are the permissions for an actor- and object-based authorization where the directory is the object
  • File permissions include actor, object and action
  • ... (add Krang, SPOPS, and Gestinanna ) ...

Usually action is represented by an enumeration or bitmask values. Could 'action' be an actual coderef? Can authz code be wrapped around any sub in a Hook::WrapSub manner?

For command-line apps, a simple 'you do not have permission' message is ok. For GUI apps, the user expects to only see an option if it can be performed. So, an authz/perms system should be able to list the permitted actions for a context.

Since permissions themselves are 'a thing' or 'things', there might be permissions for permissions. Should this functionality be built in by default?

Permissions should work with groups--groups of actions, groups of actors and groups of objects. Krang's permissions, for instance, only work with groups. But this may be tricky for a generic authz module, which would have to be told what's in groups, where groups are based on data for the rest of the application.

... more rambles to come...

* I asked some folks what the differences were between 'permissions' and 'authorizations.' The responses I got are repeated here, anonymized for everyone's protection.

They're basically the same thing.

Authorization is allowing access to a resource if the person has permission to do so. Not quite synonymous, since they can't be interchanged without breaking the grammar.

Authorization is "general permission to use the system", while permissions are handed out for every single task there is to perform

If someone has been expressly authorized, they have permission, but having permission doesn't mean they have been expressly authorized

In computers, authorization is something that permissions can allow or deny