Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DeleteTask not working with ACLs #1088

Open
ogmueller opened this issue Jul 3, 2019 · 8 comments
Open

DeleteTask not working with ACLs #1088

ogmueller opened this issue Jul 3, 2019 · 8 comments

Comments

@ogmueller
Copy link

We are using file access control lists (ACLs) on our Linux systems because otherwise, we are not able to delete web server created files (e.g. caches or session files) with a non-root CLI script.

Example: we use setfacl on our cache directory like
setfacl -R -m u:www-data:rwX -m u:some-user:rwX cache

If the web server (www-data) is creating files in that folder, it looks like this

$ ll cache/
total 556
drwxrwxrwx+ 1 www-data www-data 11026 Jul  3 09:37 ./
drwxrwxrwx+ 1 www-data www-data    16 Jul  3 09:18 ../
-rw-------+ 1 www-data www-data   796 Jul  3 08:52 some_file

or with getfacl cache/some_file like this

$ getfacl cache/some_file
# file: some_file
# owner: www-data
# group: www-data
user::rw-
user:www-data:rwx		#effective:---
user:some-user:rwx		#effective:---
group::rwx			#effective:---
mask::---
other::---

Currently those files cannot be delete using DeleteTask like

<delete includeemptydirs="true">
  <fileset dir="cache/">
    <include name="**/*" />
  </fileset>
</delete>

even though some-user is able to delete those files on the console. The only unusual thing is just, that the console is confirming the removal, if rm is used without -f option

$ rm cache/some_file
rm: remove write-protected regular file 'cache/some_file'?

Alternatively you could also use rm -f cache/some_file to aviod the confirmation and the file is removed immediately.

Would it be possible to enable DeleteTask to delete ACLs (unprotected) files as well? Maybe with an attribute to "force" the delete? (force = true, default = false)

@siad007
Copy link
Member

siad007 commented Aug 10, 2019

@ogmueller I like your idea and we should support acl on other tasks (i.e. mkdir task) as well, but we also have to respect windows support. Any ideas?

@ogmueller
Copy link
Author

I would like to help, but I have no Windows server at my disposal nor deep knowledge about this topic. As far as I know Windows is using icacls, which are an equivalent to *nix ACLs.

There is a github project dealing with windows permissions (https://github.com/stevebauman/WinPerm)

@sustmi
Copy link
Contributor

sustmi commented Oct 1, 2019

@ogmueller: What is the output of getfacl cache?
When deleting a file, you actually need a write permission for the directory in which the file is stored.
Missing write permissions for the file itself only causes rm command to ask if you really want to delete the file. But unlink() PHP function does not care about the permissions of the file itself.

@sustmi
Copy link
Contributor

sustmi commented Oct 1, 2019

Also, please note that you should look at "effective" permissions. Those are the permissions that are actually checked. In your example, the file cache/some_file has ACLs:

user:some-user:rwx		#effective:---
mask::---

This says that user some-user has assigned rwx but because all of these permissions are masked, the effective permissions are none.

If you look into the manpage of acl you can see that:

If the ACL has an ACL_MASK entry, the group permissions correspond to the permissions of the ACL_MASK entry.

What this says is that when you use ACLs, the mask is equal to the standard pemissions for the group.
That means, that you can set the mask to rwx either by:
setfacl -m mask:rwx some_file
or
chmod g=rwx some_file

The problem comes when some code is unaware of existence of ACLs and changes group permissions which actually changes the mask and also the effective permissions of ACLs.

@ogmueller
Copy link
Author

$ getfacl cache/

# file: cache/
# owner: jenkins
# group: jenkins
user::rwx
user:www-data:rwx
user:jenkins:rwx
group::rwx
mask::rwx
other::rwx
default:user::rwx
default:user:www-data:rwx
default:user:jenkins:rwx
default:group::rwx
default:mask::rwx
default:other::rwx

@sustmi
Copy link
Contributor

sustmi commented Nov 15, 2019

Sorry for not responding earlier. So in this situation (I am referring to the output of getfacl cache/ command) you cannot delete a file inside the cache directory using:

<delete includeemptydirs="true">
  <fileset dir="cache/">
    <include name="**/*" />
  </fileset>
</delete>

?

Under what user do you run Phing?

I have just created a cache directory as root:

$ sudo mkdir cache
$ sudo setfacl -m u:myuser:rwX -m default:u:myuser:rwX cache/
$ getfacl cache/
# file: cache/
# owner: root
# group: root
user::rwx
user:myuser:rwx
group::r-x
mask::rwx
other::r-x
default:user::rwx
default:user:myuser:rwx
default:group::r-x
default:mask::rwx
default:other::r-x

Then I created a file inside this directory - still as root:

$ sudo touch cache/test
$ getfacl cache/test 
# file: cache/test
# owner: root
# group: root
user::rw-
user:mirek:rwx			#effective:rw-
group::r-x			#effective:r--
mask::rw-
other::r--

When I run a target containing the above <delete> task, it works:

Buildfile: /path-to-my-project/build.xml
 [property] Loading /path-to-my-project/build/build.local.properties

My Project > mytarget:

   [delete] Deleting 1 files from cache

BUILD FINISHED

Total time: 0.0920 seconds

And the file gets deleted:

ls -la cache/
celkem 16
drwxrwxr-x+  2 root root 4096 15. lis 12.00 .
drwxrwxr-x+ 19 root root 4096 15. lis 11.55 ..

I can even zero the mask before deleting the file and Phing still deletes it:

setfacl mask::0 cache/test

What is your output/error when you run the Phing task? And what files are left not deleted (what permissions do they have)?

@stale
Copy link

stale bot commented May 13, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix label May 13, 2020
@siad007 siad007 removed the wontfix label May 17, 2020
@stale
Copy link

stale bot commented Jan 9, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix label Jan 9, 2022
@mrook mrook added this to the 3.1.0 milestone Nov 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

5 participants