[Koha-devel] Intranet Security

[Anthony W Youngman]

Looking at the way it works (as posted by Paul), I was struck that it
didn't seem to have the ability to delete anywhere. Maybe that's
deliberate - you want to keep records of what you had, and there's a
flag to say the record is dead? I haven't actually used Koha at all (I
ended up following this list by accident - I'm a database specialist).
And I hadn't seen Paul's message before I responded.
 
But what I was thinking, for easy admin, is a box with "read", "write",
"add", "delete" as the column headings, and the various objects (branch,
book, biblio, whatever) as the rows. You could call this up for groups,
users, or default, and then you tick what's allowed. So the
administrator can create groups called "borrower", "desk clerk",
"librarian" or whatever and give them permission sets. The critical
thing here is that by making the groups equal to job function (eg desk
clerk looks after borrowing, librarian looks after the collection), you
could allocate the correct permissions for the task, and if a person has
multiple roles, you just make them a member of multiple groups. Because
permissions are additive at the group level, somebody in both groups
could do both things.
 
But, if the administrator decided to add a user-acl for a particular
user, the creation would initially load the screen with their group
rights. Let's assume we have a user who needs access to a section, but
rarely uses it and has a habit of making mistakes. You could remove
their write-access. Or you want a desk clerk to do a subset of librarian
functions, but don't want them to be able to change anything - so you
just give them "add" access. This would be great for getting someone
inexperienced to add biblios for example - they can add but they can't
change what's already there.
 
This again fits in with my administrator paranoias - it's very rare for
people to damage things deliberately (I have met that :-( but quite
common to make mistakes. Our corporate philosophy is "read everywhere,
write only in your own department" and that is specifically to prevent
ACCIDENTAL damage to other people's data. ACLs really are great for
this.
 
The problem I see with the flag setup that Paul has posted is that it
does not look transitively complete to me. I would separate being able
to add data from being able to change data. And can you set it per
group, or do you have to set it per user?
 
It looks to me very practical for its purpose. It's just that I've
learnt from experience that it always pays to solve the general problem
and let the specific problem solve itself, rather than tackle the
specific problem directly. This looks to me like a
specific-problem-solution :-(
 
The main thing I hate about the NT scheme is that *all* permissions are
additive by default. So if a user has rights by virtue of the group they
belong to then you can't take them away :-( This scheme (like Primos)
says "if you hit a user acl then group acls are *ignored*!
 
Cheers,
Wol

-----Original Message-----
From: Dave Thorne [mailto:mmmbena1 at hotmail.com] 
Sent: 23 April 2003 13:11
To: Anthony W Youngman; koha-devel at lists.sourceforge.net
Subject: RE: [Koha-devel] Intranet Security



> Far better (if possible) to look at ACLs. And don't copy the NT way of

> doing it. 

What would you argue as the negative aspects of grouped permissions in
the scope of Koha(whether NT used something similar or not)?

> I would probably have four permissions per object, namely add, delete,

> read and write (need rw to edit, ad to move). And I don't know how
many 
> objects - presumably branches, books, and loans to name the obvious. 

I too am a great fan of ACLs. I use and administer linux every day and
the scope and flexibility that the ACL permission framework affords is
beyond anything else I have seen in other operating systems. My
misgivings about using it in this context would be how user friendly it
would be. Assuming we want to make the experience of administering Koha
as simple and as straight forward as possible, I would see group
permissions as greatly simplifying that process.

In saying this, however much practical knowledge of ACLs I have, I have
never implemented them in any solution of mine. Could you explain (for
my benefit more than anyone else's) how you would envisage the
permissions section to work? Both from the point of view of initial
setup of the ACLs and of the day to day user admin?

:o)

Dave

-----Original Message----- 

From: Dave Thorne [mailto:mmmbena1 at hotmail.com] 
Sent: 19 April 2003 03:14 
To: koha-devel at lists.sourceforge.net 
Subject: Re: [Koha-devel] Intranet Security 
I must say that although the library I am speaking on behalf of would 
not need more than one layer of security abstraction, for larger systems

I believe it would be necessary. In order to make Koha as 'marketable' 
as possible (in the least capitalistic way) such a permissions based 
user environment would be greatly preferred, giving more configurability

(and therefore leaving Koha available to a wider potential user base) 
which can only be a good thing. As long as the extra work required to 
manage such permissions is kept to an absolute minimum so as not to 
impinge on the experience of smaller libraries we should be on to a 
winner. How about permission groups? Then you could set up 'desk clerk' 
and 'librarian' as two seperate groups (or user types) with the 
associated permissions set to the groups, and simply add users to or 
remove them from these groups. The act of setting every possible 
permission for a new user is then made a thousand fold easier. 
Although I admit I have not yet looked at the user administration 
section in detail, I can't imagine it would take much to implement. Any 
comments? 
Dave 
----Original message from jferraro follows---- 
I have been thinking about the current intranet security setup whereby 
any staff member can access any part of the intranet. Is this the policy

in the libraries that are currently using Koha? It may be important to 
some of the larger systems (where more than a dozen people are using the

intranet) to increase the levels of password protection. My concern is 
less of a control issues and more of an "oops I just deleted our main 
branch" issue. Even adding one more layer by seperating the admin from 
the normal staff functions might be useful. Even better, maybe users 
could be added and given "permission" to access parts of the intranet. 
What does everyone think? 
Joshua 
_____ 
Want your email in a hurry? Get 
Hotmail direct to your mobile 
------------------------------------------------------- This sf.net 
email is sponsored by:ThinkGeek Welcome to geek heaven. 
http://thinkgeek.com/sf _______________________________________________ 
Koha-devel mailing list Koha-devel at lists.sourceforge.net 
https://lists.sourceforge.net/lists/listinfo/koha-devel 
<< InterScan_Disclaimer.txt >> 

  _____  

Express yourself with cool emoticons. Get MSN Messenger
<http://g.msn.com/8HMKENUK/2746> today. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20030423/ff3a333d/attachment-0002.htm>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: InterScan_Disclaimer.txt
URL: </pipermail/koha-devel/attachments/20030423/ff3a333d/attachment-0002.txt>