Discussion:
[ILUG] Directory permissions
Kevin Philp
2017-04-10 16:07:09 UTC
Permalink
At work we have a lot of files shared over nfs4. Our users need read/write
access to the shared directory. Today one of our users accidently deleted a
major sub directory on a project containing hundreds of files. We recovered
all the files and they are backed up but it was a nuisance. So how do I
provide rw access to a group working on files in a directory but stop them
moving or deleting the whole directory?

If I set the permissions rwxr-x--- they can't make new files in the
directory

If I set the permissions rwxrwx--- they can delete the directory

Any suggestions welcome

Kevin.
--
Irish Linux Users Group
---
You received this message because you are subscribed to the Google Groups "ILUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ilug+***@linux.ie.
To post to this group, send an email to ***@linux.ie.
Visit this group at https://groups.google.com/a/linux.ie/group/ilug/.
To view this discussion on the web, visit https://groups.google.com/a/linux.ie/d/msgid/ilug/86c78288-21cd-4d1f-9933-b8851edb5cd8%40linux.ie.
Paul Mc Auley
2017-04-10 21:22:49 UTC
Permalink
So, directory permissions are just that they effect the ability to
make changes to the list of files in the directory. If there is a
directory with existing files but and no write access available to the
user on the directory itself, the user can change the file but not the
directory's representation of that file.
For example:

$ mkdir foo
$ cd foo
$ touch hello.txt
$ sudo chown root .

Now, unless you have some unusual umasks you are in a directory which
you don't own and don't have write access to, which contains a file
you do own and have write access to.
You can change that file's contents (because that's a property of the
file). But you can't rename it, because that's a property of the
directory.

There are things you can do with sticky bits, setattr or selinux
contexts too but that's rapidly getting to the point where you have
problems maintaining the whole thing in a matter that's easily
understood by (say) a new member of staff and as such is out of scope.

This means that your userbase could edit files (assuming write access
to the files on a group basis), but can neither remove nor create new
files. It may also break anything which attempts to write the files as
a temp name and move them into place. That said, you could have
per-user or sub-group directories where you apply different permission
models.

The _other_ answer (which is also out of scope) is "don't do it that
way", it sounds like the sort of scenario where you should be using
change control in some form, check out a copy, make changes, check
them in. Roll back when something goes sour, trial by combat for merge
conflicts.

Paul
Post by Kevin Philp
At work we have a lot of files shared over nfs4. Our users need read/write
access to the shared directory. Today one of our users accidently deleted a
major sub directory on a project containing hundreds of files. We recovered
all the files and they are backed up but it was a nuisance. So how do I
provide rw access to a group working on files in a directory but stop them
moving or deleting the whole directory?
If I set the permissions rwxr-x--- they can't make new files in the
directory
If I set the permissions rwxrwx--- they can delete the directory
Any suggestions welcome
Kevin.
--
Irish Linux Users Group
---
You received this message because you are subscribed to the Google Groups "ILUG" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at https://groups.google.com/a/linux.ie/group/ilug/.
To view this discussion on the web, visit
https://groups.google.com/a/linux.ie/d/msgid/ilug/86c78288-21cd-4d1f-9933-b8851edb5cd8%40linux.ie.
--
Irish Linux Users Group
---
You received this message because you are subscribed to the Google Groups "ILUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ilug+***@linux.ie.
To post to this group, send an email to ***@linux.ie.
Visit this group at https://groups.google.com/a/linux.ie/group/ilug/.
To view this discussion on the web, visit https://groups.google.com/a/linux.ie/d/msgid/ilug/CADuf5h%3DV4PcqWZp%2Bp6joSFPRp9s0%3DrBu%2BegMiAQ%2BmB1VTiL7YQ%40mail.gmail.com.
paul
2017-04-11 10:16:13 UTC
Permalink
I may be missing something, but why can't you just set the sticky bit on
that directory and the one above it?


Presumably, they deleted a directory they didn't own.
Post by Kevin Philp
At work we have a lot of files shared over nfs4. Our users need
read/write access to the shared directory. Today one of our users
accidently deleted a major sub directory on a project containing
hundreds of files. We recovered all the files and they are backed up but
it was a nuisance. So how do I provide rw access to a group working on
files in a directory but stop them moving or deleting the whole directory?
If I set the permissions rwxr-x--- they can't make new files in the
directory
If I set the permissions rwxrwx--- they can delete the directory
Any suggestions welcome
Kevin.
--
Irish Linux Users Group
---
You received this message because you are subscribed to the Google Groups "ILUG" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at https://groups.google.com/a/linux.ie/group/ilug/.
To view this discussion on the web, visit
https://groups.google.com/a/linux.ie/d/msgid/ilug/86c78288-21cd-4d1f-9933-b8851edb5cd8%40linux.ie
<https://groups.google.com/a/linux.ie/d/msgid/ilug/86c78288-21cd-4d1f-9933-b8851edb5cd8%40linux.ie?utm_medium=email&utm_source=footer>.
--
Irish Linux Users Group
---
You received this message because you are subscribed to the Google Groups "ILUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ilug+***@linux.ie.
To post to this group, send an email to ***@linux.ie.
Visit this group at https://groups.google.com/a/linux.ie/group/ilug/.
To view this discussion on the web, visit https://groups.google.com/a/linux.ie/d/msgid/ilug/19edeecf-c56d-37e2-c5c3-71262427b892%40420blaze.it.
Damian Price
2017-04-11 13:00:34 UTC
Permalink
New to Linux. Sticky bit?

Damian
Post by paul
I may be missing something, but why can't you just set the sticky bit on
that directory and the one above it?
Presumably, they deleted a directory they didn't own.
Post by Kevin Philp
At work we have a lot of files shared over nfs4. Our users need
read/write access to the shared directory. Today one of our users
accidently deleted a major sub directory on a project containing
hundreds of files. We recovered all the files and they are backed up but
it was a nuisance. So how do I provide rw access to a group working on
files in a directory but stop them moving or deleting the whole directory?
If I set the permissions rwxr-x--- they can't make new files in the
directory
If I set the permissions rwxrwx--- they can delete the directory
Any suggestions welcome
Kevin.
--
Irish Linux Users Group
---
You received this message because you are subscribed to the Google Groups "ILUG" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at https://groups.google.com/a/linux.ie/group/ilug/.
To view this discussion on the web, visit
https://groups.google.com/a/linux.ie/d/msgid/ilug/86c78288-21cd-4d1f-9933-b8851edb5cd8%40linux.ie
<https://groups.google.com/a/linux.ie/d/msgid/ilug/86c78288-21cd-4d1f-9933-b8851edb5cd8%40linux.ie?utm_medium=email&utm_source=footer>.
--
Irish Linux Users Group
---
You received this message because you are subscribed to the Google Groups "ILUG" group.
Visit this group at https://groups.google.com/a/linux.ie/group/ilug/.
To view this discussion on the web, visit https://groups.google.com/a/linux.ie/d/msgid/ilug/19edeecf-c56d-37e2-c5c3-71262427b892%40420blaze.it.
--
Irish Linux Users Group
---
You received this message because you are subscribed to the Google Groups "ILUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ilug+***@linux.ie.
To post to this group, send an email to ***@linux.ie.
Visit this group at https://groups.google.com/a/linux.ie/group/ilug/.
To view this discussion on the web, visit https://groups.google.com/a/linux.ie/d/msgid/ilug/194C4CE4-EDA6-4AB2-9B75-B7F6E0347E9F%40gmail.com.
Kevin Philp
2017-04-11 13:32:04 UTC
Permalink
From http://www.thegeekstuff.com/2013/02/sticky-bit/

A Sticky bit is a permission bit that is set on a file or a directory that
lets only the owner of the file/directory or the root user to delete or
rename the file. No other user is given privileges to delete the file
created by some other user.

It sounds what I need but if I think the problem is all the users are split
into groups and the directory in question has the same group membership. So
- I may be wrong here - but it looks like if I am in the group I can delete
the directory - and that is what happened.
Post by Kevin Philp
At work we have a lot of files shared over nfs4. Our users need read/write
access to the shared directory. Today one of our users accidently deleted a
major sub directory on a project containing hundreds of files. We recovered
all the files and they are backed up but it was a nuisance. So how do I
provide rw access to a group working on files in a directory but stop them
moving or deleting the whole directory?
If I set the permissions rwxr-x--- they can't make new files in the
directory
If I set the permissions rwxrwx--- they can delete the directory
Any suggestions welcome
Kevin.
--
Irish Linux Users Group
---
You received this message because you are subscribed to the Google Groups "ILUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ilug+***@linux.ie.
To post to this group, send an email to ***@linux.ie.
Visit this group at https://groups.google.com/a/linux.ie/group/ilug/.
To view this discussion on the web, visit https://groups.google.com/a/linux.ie/d/msgid/ilug/23f2debc-04fe-4f92-9fc3-57ebcbd7109d%40linux.ie.
Vanush "Misha" Paturyan
2017-04-11 14:11:25 UTC
Permalink
Post by Kevin Philp
From http://www.thegeekstuff.com/2013/02/sticky-bit/
A Sticky bit is a permission bit that is set on a file or a directory that
lets only the owner of the file/directory or the root user to delete or
rename the file. No other user is given privileges to delete the file
created by some other user.
It sounds what I need but if I think the problem is all the users are split
into groups and the directory in question has the same group membership. So
- I may be wrong here - but it looks like if I am in the group I can delete
the directory - and that is what happened.
There's a bit at the bottom of the document you reffering to:
"Different OS behave differently with sticky bits as explained in this
wikipedia article. For example, Linux only looks for sticky bit if a
user tries to rename a file. It will not check the sticky bit if a
file is being deleted."

So sticky bit won't help, not on a Linux box. But you did not specify
what is your underlying FS? If I remember correctly ZFS has a much
more granular permission system for files. If it is not ZFS and it is
impossible to migrate to ZFS then I'd say SELinux or Apparmor (and I'm
not even sure about Apparmor to be honest) is your only solution. If
your server is CentOS or RedHat then SELinux is already there, all you
need to figure out is mapping of contexts.

Even more hacky way of doing it might be the bunch of "inotify"
processes that monitor your directories for changes, but again I'm not
sure you can cancel a delete request that way (at least you'll get
notified that someone deleted a directory before users confess to
doing it).

Cheers,

Misha
--
Irish Linux Users Group
---
You received this message because you are subscribed to the Google Groups "ILUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ilug+***@linux.ie.
To post to this group, send an email to ***@linux.ie.
Visit this group at https://groups.google.com/a/linux.ie/group/ilug/.
To view this discussion on the web, visit https://groups.google.com/a/linux.ie/d/msgid/ilug/CAJ4iq3QRxLiNPHmVE88Huov7FnRC%2BAmxA514WzcnUAnZVH1D3g%40mail.gmail.com.
Loading...