koha-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Koha-devel] Intranet Security


From: Dave Thorne
Subject: RE: [Koha-devel] Intranet Security
Date: Wed Apr 23 07:32:07 2003

> 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:address@hidden
Sent: 19 April 2003 03:14
To: address@hidden
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 address@hidden
https://lists.sourceforge.net/lists/listinfo/koha-devel
<< InterScan_Disclaimer.txt >>


Express yourself with cool emoticons. Get MSN Messenger today.
reply via email to

[Prev in Thread] Current Thread [Next in Thread]