[K12OSN] Permissions for students and teachers

Chuck Kollars ckollars9 at yahoo.com
Tue Apr 8 20:28:00 UTC 2008


> Any suggestions how to set up permissions for 
> students and teachers? ...

Here's my experience when I set up a network file
storage server for a whole school using Samba a couple
years ago:

Regular *nix permissions are kinda limiting. The only
reasonable way to use "other" is if something should
be world-readable, which isn't usually the case so
mostly those permissions are irrelevant. "user"
obviously has to be the owner/creator of the file.
That just leaves "group", and there can only be one of
them. A reasonable group is something like 'all
adults'. Thus with ownership and permissions 
 joestudent facultyandstaff -rwxrwx--- 
you get a file that can be accessed both by the
student and by all adults. 

But the limitation of just one owner and one group is
hard to extend much further. [You might want to have
several groups ('faculty that teach 2009', 'class of
2010' etc.). You might even want these groups to
overlap somewhat (ex: Mr. Teacher belongs to both the
'faculty that teach 2009' and 'faculty that teach
2010' groups).] For most things finer than 'one
student' and 'all faculty' you'll need Posix ACLs.
They extend *nix file permissions to allow more than
one "owner" and more than one "group". 

As just one owner and one group was recognized as very
limiting long long ago, there are a couple tricks in
*nix that modify the scheme slightly. One is the
"setgid" bit, which if set on a directory on most *nix
systems means force the group ownership of all files
created inside that directory to be the same as the
directory itself. The other is the "sticky" bit, which
if set on non-executable files on most *nix systems
means the file can be deleted only by its
owner/creator, regardless of any other permissions on
either the file or its containing directory. 

I found traditional *nix permissions too limiting even
for a fairly simple student file storage system, in my
case because I wanted to subdivide the teachers into
several possibly overlapping groups (a desire for
'class' directories would also seem to be impossible
with just traditional *nix permissions). 

So I enabled Posix ACLs on the filesystem where all
the Samba data was stored, and manipulated them as
necessary (often by writing custom shell scripts). You
need to have Posix ACLs compiled into your kernel. You
need to have an extra parameter on the file system
line in /etc/fstab. And you need to use the ACL tools
every time a file is created. 

I found Samba wouldn't interfere with this approach 
...but it wouldn't help a whole lot either. A couple
gotchas tripped me up: 1) Samba tries so hard to
provide the same semantics as Windows that it will
even fiddle with Posix ACL inheritance in a few cases.
The result is that what you get when you create files
via *nix (ex: touch) is _not_ exactly the same as what
you get when you create files via Samba. There's no
way to entirely "fix" this (after all most don't see
it as a problem:-). There are a couple parameters in
the Samba configuration that will reduce this problem
from being even worse  ...but they won't eliminate it
entirely no matter how they're set. 2) In the Samba
world the term "ACL" means "_Windows_ ACLs". That's
all most folks care about or know about. If you ask a
question about "ACLs" it's likely the answer will just
be puzzling and the responder won't even realize you
were talking about something different. 

I took the approach of entirely abandoning any attempt
to use or simulate Windows ACLs, and did everything
with Posix ACLs. Judging from the responses I got,
this approach was quite unusual. In fact I never
managed to find anybody else who had done the same
thing and was ready to talk about it.

With the possibility of more than one "owner" and more
than one "group", I could do things like: rw by
creator, r by 'other studends of the class of nnnn',
rw by 'teachers of the class of nnnn', r by 'all
teachers', r by 'all admins', rw by 'IT staff'.

With Posix ACLs, I also set up "drop boxes" for
submitting homework (can put files in, but can't read
other files or delete any files), "public squares" for
several students to collaborate, "materials" areas
(writable only by the teacher, readable by everybody),
and "help me" areas (writable by the student and the
teacher, but nobody else). And I set up folders not
only for each student but also for each classroom
period. 

Some of these were a little tricky even with Posix
ACLs. For example both making the "drop box" behave
exactly correctly _and_ allowing deletion through
Samba of work after it had been graded didn't work
quite right for months. I eventually got the rest of
the drop box behavior to work right by removing file
deletetion altogether from the Samba side and handling
file deletion separately from the *nix side with a
'cron' job. 

Most *nix tools (for example the `cp` command) support
Posix ACLs. Backup however was a problem for me.
Neither the regular `tar` nor the then-current release
of `rsync` supported Posix ACLs. I had to get `star`,
and a non-standard version of `rsync` that supported
Posix ACLs. Posix ACL support has since been rolled
into the very latest versions of `rsync`. But those
versions aren't included in any distros yet so you may
have to fetch and/or build a special version anyway. 

In summary, it seems to me your options are:
1) KIVSS (Keep It VERY Simple Stupid)
2) Posix ACLs  - always keeping in mind that you may
have to be clever and/or override the default action
of the system to get what you want
3) Windows ACLs (no experience here)

good luck!

-Chuck Kollars


      ____________________________________________________________________________________
You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost.  
http://tc.deals.yahoo.com/tc/blockbuster/text5.com




More information about the K12OSN mailing list