15

I want to give users the ability to create write and read files in other user directory, but not to have option to delete the file after created ( sticky bit not going to work here ... ) for example :

I have user manager with directory repository
I have user worker1 that need to write files to /manager/repository but can't delete the files
I have user worker2 that need to write files to /manager/repository but can't delete the files
I have user worker3 that need to write files to /manager/repository but can't delete the files

but worker 1-2-3 can't delete the files after created only manager and root can delete the files worker 1-2-3 created.

I tried few chown and chmod tricks with applying the sticky bit without success.

fd0
  • 1,430
  • 1
  • 10
  • 14
user63898
  • 343
  • 2
  • 5
  • 12
  • 1
    Do the `worker*` users write to the directory in a certain way? You mentioned in a comment that log files go here, so does that mean a certain executable is launched to create files here? If so you could give the `worker` group `sudo` permission to run the executable as `manager`. Then the executable would create logs as the `manager` user that could be readable by the workers. – Centimane Sep 07 '16 at 18:19
  • If the user can modify the file then they can also erase its content, thus effectively "deleting" it. Looks like you need some sort of "submission" interface, not filesystems. Emails would be the simplest. – ybungalobill Mar 09 '19 at 00:29

5 Answers5

10

Unlike Windows there is no distinct delete permission under Unix/Linux. The right to delete (or create or rename) a file is bound to the containing directory. Remove the write permission for the workers on /manager/repository/ in order to deny the workers to create, delete, and rename files.

Note that it is not possible to permit creation of files but to deny their deletion.

countermode
  • 7,373
  • 5
  • 31
  • 58
  • how can remove the write permission as the file will be writen all the time it is log file – user63898 Sep 07 '16 at 11:24
  • While that used to be true, many modern systems support extended ACLs (NFSv4 ACLs as supported by FreeBSD, Solaris or Linux (Richacl patch) that give similar capabilities as Windows NT ACLs. Your stock Linux distribution is likely not to have it though. – Stéphane Chazelas Sep 07 '16 at 12:14
  • @user63898 you remove write permissions from the directory the file 's in, not from the file itself. – GnP Sep 07 '16 at 12:30
7

First of all make sure ACL is enabled in your system, then run this command

setfacl -d -R -m user::rwx,user:worker1:---,user:worker2:---,user:worker3:--- \
/manager/repository

How it works

  • This command will give give read, write and execute permissions for the owner on the directory /manager/repository. It will revoke all permissions for worker1, worker2 and worker3.

  • This will give other users, read & write access but will deny the delete access.

From man setfacl:

-d, --default
       All  operations  apply to the Default ACL.

-R, --recursive
       Apply operations to all files and directories recursively.

-m, --modify
       Options to modify the ACL of a file or directory.
Rahul
  • 13,309
  • 3
  • 43
  • 54
  • thanks , but the problem is that users are created all the time . and some are deleted by the admin . so that means i need to each time update the directory with the setfacl ? is there any more generic solution? – user63898 Sep 07 '16 at 09:55
  • yes when i try to create file from worker1 touch /manager/repository/x.txt im getting : touch: cannot touch `/manager/repository/x.txt': Permission denied – user63898 Sep 07 '16 at 10:21
  • still getting Permission denied when i do ls -ld repository im getting : drwxrwxr-t 2 manager users 4096 Sep 7 11:30 repository/ – user63898 Sep 07 '16 at 10:48
  • when doing setfacl -d -R -m user::rwx,user:worker1:--- repository/ and then trying to create file from worker1 touch /manager/repository/x.txt im getting : touch: cannot touch ` /manager/repository/x.txt': Permission denied – user63898 Sep 07 '16 at 11:03
  • why i have to give the full path ? – user63898 Sep 07 '16 at 11:09
  • @user63898 Relative paths will work, too. – Paul Nordin Sep 07 '16 at 17:48
  • 7
    wouldn't this still allow someone to write an empty file here? Like `echo " " > $file` would clobber the file contents with " ", which is technically a write, but effectively deletes the contents. It seems like an actual repo like svn would be the best bet here. – Centimane Sep 07 '16 at 18:14
  • @user63898 You get permission denied as `worker1` because the `---` revoked all of worker1's permissions. – Paul Nordin Sep 07 '16 at 18:31
3

To do that with permissions, you'd need a system with support for ACLs similar to NFSv4 ACLs. For instance, on FreeBSD, if the filesystem is mounted with the nfsv4acls flag, you can do:

mkdir testdir
chown manager:worker-group testdir
chmod 775 testdir
setfacl -m group@:D::deny testdir

To explicitly deny the delete_child permission to members of the worker-group group.

However note that since the workers would be owners of the files they create, they would still be able to modify the ACLs on them, and by granting themselves the delete permission, that would take precedence over the delete_child permission of the parent directory and I'm not sure there's a way around that (at least on UFS filesystems on FreeBSD). For instance they could do:

$ touch file
$ rm -f file
rm: file: Operation not permitted
$ setfacl -m owner@:d::allow file
$ rm -f file
$
Stéphane Chazelas
  • 522,931
  • 91
  • 1,010
  • 1,501
1

we can modify the files and folders but can't delete.

To remove the attributes, run the following commands:

For files:

$ sudo chattr -R -a file.txt

For directories:

$ sudo chattr -R -a dir1/
Jeff Schaller
  • 66,199
  • 35
  • 114
  • 250
Ankitsrivasta
  • 46
  • 2
0

To take write permissions from the /manager/repository folder. So, all the users who are not root will be able to write or delete from the files inside /manager/repository, but not to delete any file from this directory.

chmod 755 /manager/repository
slm
  • 363,520
  • 117
  • 767
  • 871
Josef Klimuk
  • 101
  • 3