How does provisionacl work for new files created by a user from the client group?
The aegir user does not seem to have the privileges to update the acl on such a file. Which would need help from e.g. the root user to fix.

Comments

ergonlogic’s picture

ergonlogic
he/him
Primary language English
Location Montréal, Québec 🇨🇦
commented
Status: Active » Needs review

This and this would seem to indicate that the aegir user should get full rwx access recursively within the managed directories.

helmo’s picture

helmo commented

The aegir user does indeed have write access. However setfacl gives and "Operation not permitted" error.

As the file is owned by e.g. helmo and not by aegir only helmo would be allowed to change the acl.
The same seems to go for files created by the webserver, e.g. css aggration files.

ergonlogic’s picture

ergonlogic
he/him
Primary language English
Location Montréal, Québec 🇨🇦
commented

Indeed, the setfacl docs describe the following permissions:

The file owner and processes capable of CAP_FOWNER are granted the
right to modify ACLs of a file. This is analogous to the permissions
required for accessing the file mode. (On current Linux systems, root
is the only user with the CAP_FOWNER capability.)

I would think granting the CAP_FOWNER capability to aegir processes would be out of the question...

helmo’s picture

helmo commented

Then I wonder how this has been used in the past. Was it a different usecase?

anarcat’s picture

anarcat commented
Status: Needs review » Postponed (maintainer needs more info)

So the thing is that aegir creates a set of default ACLs anyways, so those files *already* have the proper ACL. Aegir doesn't check before setting them so it tries anyways and fails, but that doesn't matter because the ACLs are inherited.

So while, yes, we could use sudo or capabilities (i'd prefer the latter) to fix that problem, it only makes it so there's no warning, it shouldn't affect functionality.

Or are you having problems with ACLs not actually being correct on those files?

helmo’s picture

helmo commented

Well the main motivation was the warnings in the task log, since the task becomes yellow it will keep attracting attention...
Reading and writing the file content is fine, I just haven't tested all scenarios, like migrate.
So I would either add a test to avoid the warning, or fix it properly.

helmo’s picture

helmo commented

note to self: we would need the CAP_FOWNER capabilities.
Debian package libcap2-bin

Can we set this globally for the aegir user, or does it need to be per script ( drush ? )

valkum’s picture

valkum commented
Issue summary: View changes

I ran into this problem here too on my site.
As a workaround i created a little script which is executed via a root cronjob.
https://gist.github.com/valkum/9820479
As we have some guys who add themes per site i have to change the owner of the theme folders to.
If you have any suggestions to handle this a proper way don't be shy.

Simply put the script it somewhere and add to our roots crontab file
* * * * * /<Path>/acl_fix.sh
to run this every minute.