[K12OSN] Student problem

[Paul Davison]

Hi Jim,

Might I suggest the following (untried, but my brain seems to think it 
works :)

. make all teachers part of the teacher group
. set the owner:group for drop to root:teachers
. all of the teachers by default have thier own group, so set the 
owner:group for each teacher directory (Mrs.Smith) to root:mrssmith
. set the permissions to 773  (or rwxrwx-wx)

This allows any student to drop a file into a teachers drop box, but 
they cannot read it. The teachers each have access to thier own 
directory for read and write.

If you are going to the level of having a seperate directory for each 
class the teacher has, then set the owner:group on those directories to 
mrssmith:mrssmithsclassgroup with the perms set to 730 (rwx-wx---). This 
would allow only students in the mrssmithclassgroup to save files in 
that class directory. You could use this method to set the 
subdirectories up by grade level as well.

Linux owner/group/other permissions do seem restrictive at the start, 
but there is usually a way to make it all behave the way you want within 
those perameters. It all goes back to how your groups are laid out.

Hope this helps

Paul


Jim Kronebusch wrote:

> I agree with what you are saying, I keep thinking "what am I doing wrong
> that this doesn't make more sense".  No matter what I want every user to
> have to deal with one username and password combo, anything more just
> pisses us all off :-)  I want the list of share points to be simple when
> a user logs in and don't want them traversing all over to get access.
> So if I have a share of 'Drop' with 'TeacherX,Y, and Z' under it I need
> to let groups "Students" and "Teachers" into share 'Drop'.  Then every
> teacher wants 'ClassX, Y, and Z' under their folder with another set of
> permissions.  I think the main problem is I just confuse myself when I
> think too much.  I will go back and re-evaluate directory structure and
> try to come up with a more efficient way to propogate users along with
> permissions given the user,group,other limit.  Heck, just even
> describing this makes me think there is a better way :-) 
> 
> Thanks for the info on the ACL's.  I just wanted to make sure I wasn't
> missing something stupid.
> 
> 
>>Traditional unix filesystems only store the owner/group numbers and
> 
> the permission bits for those plus everyone else - it isn't the GUI that
> 
> 
>>restricts this.  Note that your problem comes from wanting a 'group'
> 
> of owners, though.  If each drop is owned by a single teacher, or you
> make an 
> 
>>extra login to own it and give the password to the appropriate people
> 
> you get the sets of permissions you need and they will stay put with
> most 
> 
>>copy/backup/restore methods. 
>>Newer filesystems permit exceptions to the policies through ACL's but
> 
> in general if you need a lot of exceptions it indicates something is
> wrong with > the policy and if you use them you'll need special support
> every time you think about moving things.
> 
> ---
>   Les Mikesell
>    les at futuresource.com
> 
> 
> 
> _______________________________________________
> K12OSN mailing list
> K12OSN at redhat.com https://www.redhat.com/mailman/listinfo/k12osn
> For more info see <http://www.k12os.org>
> 
> 
> _______________________________________________
> K12OSN mailing list
> K12OSN at redhat.com
> https://www.redhat.com/mailman/listinfo/k12osn
> For more info see <http://www.k12os.org>