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

Re: [K12OSN] Dropbox question



On Thu, 2006-12-21 at 09:30 -0600, Petre Scheie wrote:

> > One mandatory suggestion if you want to do it this way, set the sitcky 
> > bit, making the permissions 3777. This will prevent students from 
> > deleting one another's files.
> > 
> Users can't delete each other's files even without setting permissions to
> 3777 because the default permissions, as dictated by the umask, set Other
> to r-x.  Even if the folder the files are being put into is set 777, the
> files themselves will still be owned by the student who put them there,
> and the Other perms will be rx, meaning no other student can delete those
> files.

That's not true.  On unix-like systems, the ability to delete files is
determined by the containing directory permissions, not the file itself.
The sticky bit on the directory changes this so that you must also have
write permission on the file to delete it.

> Setting the sticky bit for Group on the folder, aka sgid, and 
> having only the teacher be a member of that group means the teacher and only the teacher 
> will be able to write (delete) the students files, in addition to reading them, in that 
> folder.

RH/fedora based systems normally default to a umask of 0002, which makes
newly created files rw by group by default, and they create a group for
each user.  If you add the teacher(s) to each student's group, they will
automatically get read/write access to the student's files, dropbox or
not.

>  If you don't want the students to be able to even read each others files in 
> dropbox, set the permissions to 2773 which will make the folder writeable and executable 
> but not readable for Other, meaning the students.

Not being able to read the directory will keep you from seeing the
filenames
but if you can guess the name and have read permission on the file
itself
you can still access it.  The 'teacher in students group' scheme lets
students see the filenames but not have any access to each other's file
contents.

-- 
  Les Mikesell
  les futuresource com



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