Thanks :)

The obvious one is to just change the ownership of the files after running grunt. Something like:

chown www-data:www-data /path/to/file

Or if you want to recursively take ownership of a directory:

chown -R www-data:www-data /path/to/file

Or is you wish to avoid having to do that each time, you could run the grunt command as the www-data user. You can do that with su. Sorry, I haven't double checked this - so may need minor adjustment, but something like this should work:

su - www-data -s /bin/bash -c "grunt command"

If your command needs double quotes, you can either just use single quotes as the outside quotes of escape the inner quotes (i.e. precede each inner quote with \).

FWIW you need to explicitly define a shell ('-s /bin/bash' in above command) when you run a command as www-data. You could use /bin/sh or any of the other shells instead and it would work just as well, bash is just my preference. By default www-data has no shell as a security measure. Otherwise, (at least in in theory) an attacker who gained control of your webserver (e.g. via a security vulnerability in Magento in your case) could run shell commands on your system! Even as a limited user, a fair bit of damage could be done. And daisy chained with a (separate and theoretical) privilege escalation bug, all bets are off!

Another (relatively) "safe" option (which will require much more set up) would be to create a new user who has default membership of the www-data group and either log in as that user or use sudo to run commands as that user. Create the user like this:

adduser www-data-user --no-user-group --gid www-data

Then either log in as that user, or run the commands with sudo like this:

sudo -u www-data-user grunt command

(Note that sudo may need to be installed via apt).

That does have some potential security implications as there is now an additional user who can log in (which obviously may be desirable) - security implication that there is now an additional attack vector. That could be locked down further, but is beyond the scope of a simple answer. Having said that, so long as you set a good password, the risk are not particularly high, just worth being aware of.

TBH, as I haven't tested, I suspect that it may actually require a little more to get an additional user set up and working as you'd desire. It will possibly also require the umask to be updated for www-data-user as well as perhaps setting the "sticky bit" for the directory. Actually, it's possible that may be a third way of doing it?!

Anyway, let me know how you go.