PDA

View Full Version : allow user to save/edit/delete documents in a folder but not delete that folder



lothario
6th September 2011, 01:05 AM
Recently I setup a system for a non-technical user.
He is only using Firefox, Pidgin and OpenOffice for about 2 hours a day.
I have created a folder "/home/jim/myFiles" where he can save his document files.

But Jim has accidentally deleted his myFiles folder on 2 occasions.
He had intended to delete a file in that folder.

Is there a way to lock the folder so that the user and create/read/write documents in that folder but not delete the folder itself?

Gareth Jones
6th September 2011, 03:02 AM
What's wrong with using the normal ~/Documents folder (and its relatives)?

As for deleting it, the permission to delete or rename a file or folder is not affected by its own permissions, but the permissions of the folder containing it – specifically the parent folder's write permission. However, removing write permission from a user's own home directory isn't a great plan.

There is a rather ugly solution I can think of. Maybe one of the SELinux experts here have a better way?

1) Create a hidden directory ~jim/.files. Create at least one subdir (Documents, Pictures etc.) inside it.

cd ~jim
mkdir -p .files/{Documents,Downloads,Music,Pictures,Videos}

2) Set the permissions so that he can create files in the subdirectories but not modify .files or its immediate contents.

chmod 0750 .files/*
chmod 0550 .files

3) Create visible symlinks to the folders in .files so he can see them.

for dir in .files/*
do
link="${dir##*.files/}"
ln -s "$dir" "$link"
done

4) Use ext{2,3,4}fs attributes to protect the symlinks and .files itself.

sudo chattr +i .files Documents Downloads etc.

It's ugly but I think it'll work.

Gareth

beaker_
6th September 2011, 04:20 AM
Is there anything wrong with the sticky bit?

jpollard
6th September 2011, 05:50 AM
Any file/directory that is in a directory owned by the user can be deleted (or renamed/moved). And being moved is usually the way things are deleted as they are "moved to trash" by the GUI.

Gareth Jones
6th September 2011, 05:13 PM
Yes, I'm assuming that the user in question has his own home directory rather than a subdirectory of someone else's directory. Otherwise the sticky bit would work so long as he owned neither his documents directory nor the parent directory.

Gareth

flyingfsck
6th September 2011, 06:21 PM
How about using an ACL on the directory?

http://www.vanemery.com/Linux/ACL/linux-acl.html

jpollard
6th September 2011, 07:01 PM
Owners can still change/delete the folder - he OWNS it. Therefore the ACL does not prevent the user from deleting his own files and directories.

DBelton
6th September 2011, 07:25 PM
I would just set the immutable flag on the directory chattr +i as root user. That way, nobody, even root can't delete the directory unless the immutable flag is removed first.

PabloTwo
6th September 2011, 07:32 PM
I played with making a folder in my $HOME immutable yesterday. This won't work. Once the folder itself is made immutable, nothing inside it can be changed. Not even as root.

DBelton
6th September 2011, 07:37 PM
blah. Forgot about that one, Pablo Two..

But, if you do this, it should work

As root user:

mkdir -m 1777 foldername

Then any user should be able to create/read/write/delete files they own inside the folder, but the folder itself would be owned by root.

Gareth Jones
6th September 2011, 07:42 PM
Yes, immutable has to be used for an intermediate folder as I did above. An immutable directory cannot have any of its properties changed, including its immediate contents.

Gareth

---------- Post added at 07:42 PM ---------- Previous post was at 07:38 PM ----------


mkdir -m 1777 foldername

Then any user should be able to create/read/write/delete files they own inside the folder, but the folder itself would be owned by root.

But if the parent folder is still owned by Jim, root's ownership means nothing with respect to deleting the folder.

The sticky bit also does nothing in this situation, unless you touch a root-owned file within the directory which might actually solve the problem...

Gareth

PabloTwo
6th September 2011, 07:46 PM
As root user:

mkdir -m 1777 foldername

Then any user should be able to create/read/write/delete files they own inside the folder, but the folder itself would be owned by root.
Nope. I had no problem whatsoever deleting a folder belonging to root that was in my $HOME. I tried it several different ways.

Gareth Jones
6th September 2011, 07:48 PM
mkdir ~jim/Files
touch ~jim/Files/.lockdir
sudo chown -R root: ~jim/Files
sudo chmod 0600 ~jim/Files/.lockdir
sudo chmod 1777 ~jim/Files

The hidden .lockdir with the sticky parent should prevent deleting the directory.

Gareth

jpollard
6th September 2011, 08:01 PM
I've always been able to delete root owned files... if I own the directory they are in.

Anything that prevents a directory from being deleted does not prevent it from being renamed or moved somewhere out of the way.

The only way the sticky bit prevents things from being deleted is if root owns the directory AND the parent directory. Even then, the owner (now root) can STILL delete it.

PabloTwo
6th September 2011, 08:08 PM
mkdir ~jim/Files
touch ~jim/Files/.lockdir
sudo chown -R root: ~jim/Files
sudo chmod 0600 ~jim/Files/.lockdir
sudo chmod 1777 ~jim/Files

The hidden .lockdir with the sticky parent should prevent deleting the directory.

Gareth

Yep. I followed that procedure and failed to delete the directory I had created with the .lockdir file in it.

DBelton
6th September 2011, 08:11 PM
root being able to still delete it would still solve the OP's problem IF we could find a way to keep the user from deleting it.

I haven't tried yet the solution Gareth shows above to see if it works or not, but other than that, it looks like you would need to use a folder outside of the users home folder to be able to prevent them from being able to delete it.

hmmmm.. what if you had a folder created elsewhere and did a bind mount to place it into the users home folder?

Giving this more thought..

You could just create a regular folder with default permissions in the home folder
then create 1 file inside that folder owned by root (and set the immutable bit if you wish)

The the folder would be undeletable since you can't delete a folder until all contents under it are deleted.

Here is a clip of what I just did:


[Me@tower20 ~]$ mkdir test
[Me@tower20 ~]$ su -
Password:
[root@tower20 ~]# cd /home/Me/test
[root@tower20 test]# touch .test
[root@tower20 test]# chattr +i .test
[root@tower20 test]# ls -al
total 8
drwxrwxr-x. 2 Me Me 4096 Sep 6 14:19 .
drwx------. 92 Me Me 4096 Sep 6 14:18 ..
-rw-r--r--. 1 root root 0 Sep 6 14:19 .test
[root@tower20 test]# cd ..
[root@tower20 Me]# exit
logout
[Me@tower20 ~]$ rm -R test
rm: remove write-protected regular empty file `test/.test'? y
rm: cannot remove `test/.test': Operation not permitted
[Me@tower20 ~]$

jpollard
6th September 2011, 08:17 PM
All you need to do is "mv Files/.lockdir junk; rm -rf Files; rm junk"

The sticky parent does nothing to prevent the owner from manipulating/deleting files. Might take two steps, but it doesn't stop it.

As for bind mounts... I think the user can unmount it.

Mind - something like gvfs mounts make it harder. The bind is to a process, and you have to kill the process to get it to unmount. IF
the user doesn't have permissions to kill the process, that might prevent it.

BTW - gvfs is a fuse mount, not a bind mount.

PabloTwo
6th September 2011, 08:22 PM
Gareth's way works. I"ve been playing with this a bit just now. As a regular user, I cannot delete the folder FOO (now renamed to FANDANGO) as long as the .lockdir file was there. What's more, knowing that that hidden file was there, I also couldn't delete it as a regular user either. I am able to create and delete files in that folder as regular user, but not delete the folder itself as long as that .lockdir file in in there.

DBelton
6th September 2011, 08:24 PM
yep. it works. :)

but no need to change the owner or attributes of the folder. just the one file inside the folder so it can't be deleted.

and setting the immutable bit on the file in the directory prevents the user from movinf it..



[Me@tower20 ~]$ cd test
[Me@tower20 test]$ mv .test ~/
mv: cannot move `.test' to `/home/Me/.test': Operation not permitted
[Me@tower20 test]$

PabloTwo
6th September 2011, 08:28 PM
And me as user cannot "mv" the .lockdir file either. Just tried it.

BASH:~/-> mv FANDANGO/.lockdir work/
mv: cannot move `FANDANGO/.lockdir' to `work/.lockdir': Operation not permitted

---------- Post added at 03:28 PM ---------- Previous post was at 03:25 PM ----------


BASH:~/-> cd FANDANGO
BASH:FANDANGO/-> ls -a
. .. .lockdir
BASH:FANDANGO/-> mv .lockdir impotent
mv: cannot move `.lockdir' to `impotent': Operation not permitted

jpollard
6th September 2011, 08:39 PM
Deletes just fine here. Even with the immutable flag set.

As long a I own the directory the file is in, I can delete the file, and the directory it is in.

PabloTwo
6th September 2011, 09:00 PM
I made the directory that the .lockdir file was in owned by root and the .lockdir file owned by root and set the permissions on the folder and the .lockdir file as in Gareth's instructions. After doing that, the only way I could delete the folder was to "sudo" to root..."sudo rm -r FANDANGO/". Bang! Gone.

BASH:~/-> ll
total 48
-rw-rw-r--. 1 paulm paulm 188 2011-09-02 09:33 cef-daily
drwxr-xr-x. 2 paulm paulm 4096 2011-04-12 21:19 Desktop
drwxr-xr-x. 5 paulm paulm 4096 2010-10-14 20:52 dosbox
drwxr-xr-x. 2 paulm paulm 4096 2011-09-06 14:01 Downloads
drwxrwxrwt. 2 root root 4096 2011-09-06 15:08 FANDANGO
drwxr-xr-x. 12 paulm paulm 4096 2011-08-13 15:46 files
drwxr-xr-x. 3 paulm paulm 4096 2011-08-28 20:48 Music
drwxr-xr-x. 11 paulm paulm 4096 2011-08-25 12:54 Pictures
drwxr-xr-x. 8 paulm paulm 4096 2010-09-26 17:12 rpmbuild
drwxr-xr-x. 4 paulm paulm 4096 2011-09-04 12:42 src
drwxr-xr-x. 2 paulm paulm 4096 2011-04-27 12:59 Videos
drwxr-xr-x. 2 paulm paulm 4096 2011-08-28 15:29 work

BASH:~/-> ls -al FANDANGO/
total 8
drwxrwxrwt. 2 root root 4096 2011-09-06 15:08 .
drwx------. 64 paulm paulm 4096 2011-09-06 15:12 ..
-rw-------. 1 root root 0 2011-09-06 14:59 .lockdir

BASH:~/-> rm FANDANGO/.lockdir
rm: cannot remove `FANDANGO/.lockdir': Operation not permitted

BASH:~/-> sudo rm -r FANDANGO/
BASH:~/-> ls
cef-daily Desktop dosbox Downloads files Music Pictures rpmbuild src Videos work
Nothing was set with the immutable attribute.

---------- Post added at 04:00 PM ---------- Previous post was at 03:57 PM ----------

In using chown, I used root:root, instead of Gareth's root:, maybe that's making a difference as to why jpollard isn't locking that directory down ??

Gareth Jones
6th September 2011, 09:38 PM
Deletes just fine here. Even with the immutable flag set.

Are you using ext*fs? Does lsattr show the immutable flag?

Immutable should prevent all modification of an inode, including link counts (preventing renaming and deletion).

Gareth

---------- Post added at 09:35 PM ---------- Previous post was at 09:30 PM ----------


You could just create a regular folder with default permissions in the home folder
then create 1 file inside that folder owned by root (and set the immutable bit if you wish)

I think you have to use the immutable flag for this to work, and then the ownership doesn't matter.

So, merely


touch ~jim/Files/.lock
sudo chattr +i ~jim/Files/.lock

should make it impossible to remove the Files directory (without using chattr of course). It won't prevent renaming or moving the directory, and depending on how "rm -r" etc. proceed, you may loose the rest of the contents of the directory before it decides it can't remove the directory itself. (My first method with symlinks does at least prevent the latter scenario). Hopefully Jim is using the Trash rather than actual delete!

Gareth

---------- Post added at 09:38 PM ---------- Previous post was at 09:35 PM ----------

Also I love the maliciousness we're attributing to Jim in his desire to loose his files!

PabloTwo
6th September 2011, 10:01 PM
touch ~jim/Files/.lock
sudo chattr +i ~jim/Files/.lock
That's definitely the easiest and simplest solution. Tried it and it works. It doesn't, however, prevent Jim from creating another folder inside of ~jim/Files and placing files in that folder and then "accidentally" deleting that whole folder instead of a file(s) inside it.

I think the real solution is to give "Jim" an education about what is a folder and what is a file and to just tell him he needs to be more mindful about what he is doing, especially when it comes to deleting files. I don't know what GUI file manager environment Jim is working in, but if it's anything like the "default" I've seen in Nautilus or Thunar, then almost everything, including files, is presented with an icon that depicts a folder. In that environment, how is the uninitiated to tell the difference? Maybe switching from "Icon view" to "View Details" will help Jim better see what is what.

jpollard
7th September 2011, 12:25 AM
And I just removed the directory tree with a "rm -rf dir".

No problem.

correction.... (sorry about that) I was in the wrong place to remove it.

I was able to rename the directory without a problem. "mv dir dir2". Directory is now different, and no longer under the same name.

There is no way to prevent a user from mucking up files that are owned by that user. You can make it more complex, but it can still be done.

DBelton
7th September 2011, 01:01 AM
oh, I agree 100% there, jpollard..

There is no way to completely prevent a user from mucking up the files.

As the old saying goes:

The more I idiot proof my programs, along comes a bigger idiot

All you can do is to make it so that it's hard for them to accidentally delete them. You can't make it impossible to delete them.