-1

I've got all my files on a server raid, and it has a reasonably excessive amount of space so I'm not often going to have to delete anything.

I still have things writing to the raid all the time so I don't want to have to use sudo to do that. But is it possible to set permissions so that writing is allowed but deleting files is not?

I assume this will also require me to use sudo for mv commands, but that isn't a problem

Extra info:

Raid uses btrfs raid1

OS is on a separate drive (Ubuntu 14.04 server)

4
  • 2
    As kvbx says, you can do this ...but is this really what you want to do? Someone who can write to a file can replace its contents with whatever they like. That's often just as bad as deleting the file, and sometimes more problematic. Oct 8, 2014 at 16:22
  • It's more to protect from my own stupidity than for external threats
    – Anake
    Oct 8, 2014 at 16:31
  • Make sure you keep good backups! btrfs is still not considered totally production level item.
    – mdpc
    Oct 8, 2014 at 16:40
  • I know, I'm right this minute setting up my backup server. I almost deleted something important while preparing the transfer so thought I would check here if there was a way around accidental deletions
    – Anake
    Oct 8, 2014 at 16:56

4 Answers 4

1

You need directory write permissions to create or delete files. You need file write permissions to change the file.

Considering this tree:

FolderA: (no write permissions for you)
   - FileX (write permissions)
   - FileY (write permissions)

You can now change FileX and FileY but you can't delete them. Nor can you create a FileZ in FolderA.

1

I don't think it's possible. File creation and deletion in Unix are controlled by the ability to write to the directory --- basically the same flag.

Now what you can do is create two directories --- one with write permission and the other one restricted to root.

[romano:~/tmp/test] % ls -l
total 8
drwxrwxr-x 2 romano romano 4096 Oct  8 18:06 normal
drwxrwxr-x 2 root   root   4096 Oct  8 18:06 onlyroot

You normally work on normal. Suppose you have in it:

[romano:~/tmp/test/normal] % ls
one.txt  three.txt  two.txt

You can clearly delete files and create new ones; suppose you want to protect "one.txt" from deleting. What you can do is creating a hard link to it in onlyroot:

[romano:~/tmp/test/normal] 1 % sudo ln one.txt ../onlyroot

This will create another name for one.txt in onlyroot (using a negligible amount of space; the file is not copied). Now as a normal user you can delete one.txt in the normal folder, but you will have an untouchable version under the onlyroot one.

[romano:~/tmp/test/normal] % ls
one.txt  three.txt  two.txt
[romano:~/tmp/test/normal] % rm one.txt
rm: remove regular empty file ‘one.txt’? y
[romano:~/tmp/test/normal] % cd ..
[romano:~/tmp/test] % cd onlyroot 
[romano:~/tmp/test/onlyroot] % ls
one.txt
[romano:~/tmp/test/onlyroot] % rm one.txt 
rm: remove regular empty file ‘one.txt’? y
rm: cannot remove ‘one.txt’: Permission denied
1

In my understanding (based on https://btrfs.wiki.kernel.org/index.php/Project_ideas#RichACLs_.2F_NFS4_ACLS), btrfs supports only traditional Unix permissions and POSIX.1e ACLs, and hence can't do what you want.

Many/most other filesystems support at least one of Linux richacls (which I don't believe is in mainline yet), NFSv4 ACLs, ZFS ACLs, or Windows ACLs, all of which allow you to specifically deny 'delete', but I don't imagine you'd be willing to give up the features of btrfs just for this.

On the other hand, since you are specifically intending this to guard against simple errors, you might be better off taking advantage of btrfs's snapshot capabilities using something like autosnap.

0

I think one solution would be to just create a function in your bashrc, e.g.:

sudowrapper () { 
sudo -k;sudo "$@";sudo -K; 
}

vimf() {
    echo "pass" | sudowrapper -S nvim "$1"
}

sudowrapper is required to make sudo forget the credentials every time vimf is called, otherwise it gives weird behavior.

Do this only if you want to save you from doing something wrong yourself if your goal is to prevent others from doing something bad then writing your password in .bashrc is a bad idea.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .