Hello Wouter, Wouter Thielen wrote: > Sorry for my late reply regarding this thread.
And I am late too. It is summertime here and fun stuff is happening. > Exactly. So if the application user (let's call him appuser) was a member > of the www-data group, then the deployment script run by appuser wouldn't > need the sudo in "sudo chgrp www-data dir". That depends upon more information. Is the owner of the file www-data? Is the www-data user in the www-data group on your system? Pádraig made updates to the documentation to improve the situation. And also mentioned the "RATIONALE" section of the standards documentation. I will mention it again. http://pubs.opengroup.org/onlinepubs/9699919799/functions/chown.html As you can see different systems allow different behaviors. On some systems anyone can chown/chgrp the file. On others the capability is restricted to root. On others it is restricted to the owner of the file. It is a kernel policy based upon the kernel running your system. The RATIONALE says only that this is problem for government security regulations. I suppose that must be true but notably BSD is listed as "4.3 BSD permits the owner to change the group ID of a file to its effective group ID or to any of the groups in the list of supplementary group IDs, but to no others." Before that AT&T Version 7 Unix "permits only the superuser to change the group ID of a file." I spent a lot of time working on HP-UX which is a System V like system. An archaeologist might assume that in V7 the developers were root and knew there were issues so restricted chown/chgrp to root. System III and System V were used in business settings and had compromises applied to make them useful to businesses. Everyone using the system usually worked for the same company and therefore had a trusted status with the system. People living in the same house usually have full access to the kitchen and bath without security in the house too. BSD on the other hand needed to be secure in a less trusted environment and therefore restricted this capability. The Linux kernel follows the BSD kernel in this security model. This is an evolution of the security model. On a practical level enabling chown/chgrp without restriction as is done on System III and System V creates problems. If quotas are enabled then if a user can give away ownership of a file then the quota will be reduced for them and increased for the other person. This means that you can avoid a quota by giving all of your big files away to root. Or you can attack a user by giving large files to that other user. It will consume all of their disk quota. They won't be able to operate since they don't know where the files exist and can't remove them. Therefore enabling chown/chgrp without restriction is incompatible with quotas. On another practical level enabling chown/chgrp without restriction as is done on System III and System V causes users to trip over themselves often. They can create files that they cannot remove. This requires root administration to fix. This commonly happens when untar'ing files where the original files were owned by another user. The default tar action will restore the original ownership. If the tar file included subdirectories then the user untar'ing the bundle of files will no longer own those files and will no longer be able to remove them. Having given them away they system will now allow them to chown the files back to themselves. Again it requires root admin to fix the situation. Another problem is /tmp too. It is possible to create files there and gift them away. There are various attacks possible through /tmp and therefore the current wisdom is that /tmp should have the 't' bit, the sticky bit, set on it. Again if the user can chown files then they can create files in /tmp that cannot be removed except by the superuser requiring root admin to fix the situation. This can create a denial of service attack. > But I didn't know that because it isn't mentioned in the chgrp man > page or info page at all, that you can "change the group ownership > of the file, if the user performing the chgrp command is a member of > that group", i.e. does not need sudo. Pádraig's updates to the documentation should help. Thanks Pádraig! > If it is, as you said, because of the different operating systems having > different policies, then that is a shame. I think this specific information > does make a lot of sense, and should be accepted practice on all ported > versions of the GNU coreutils. It is difficult for the utilities to document what happens on the underlying kernel since the same utilties are run upon many different kernels. > Currently, on my Ubuntu 12.04 desktop, coreutils 8.12.197-032bb, from > September 2011, it says "Change the group of each FILE to GROUP." > May I suggest "Change the group of each FILE to GROUP. On common systems, > there will be an EPERM error when the effective user (other than root) is > not a member of GROUP." > > Or something in this fashion. Back to your deployment script: > As I stated in my e-mail, it is a deployment script. It retrieves the > latest source code from a code repository, compresses it into a .tar.gz > file, sends that file to the production server, and then runs a remote > script on the production server that extracts it and prepares the structure > for the live environment, which includes chgrp-ing and chmod-ing some > directories into that server's www-data with write permissions. And trust > me, I know which directories need such permissions. I do not put that on > DocumentRoot and deliberately recursively apply from there. The above doesn't say if the remote deployment process is running as the www-data user or another user. I think it is bad if the files are owned by the www-data user since then the web process can write those files. Unfortunately that is usually the way Wordpress is installed which is extremely popular. Unfortunately I have seen a lot of cracked sites that way. If I were doing that task I would do something along these lines. There are many different ways to do things. I am not saying this is the only way. Just that this is what I would do. I would create a special production deployment user to run the deployment process. I would do this so that it would be a different user from the www-data user that is running the web server daemon process. Let's call it www-deploy just for discussion. I would ensure at least a 02 umask setting. I would have it unpack the tar.gz file on the production web server. All of the files would be owned by the www-deploy user. The restricted chown would keep tar from changing the ownership away. The umask would prevent write permissions from other. This way with both a different owner:group and file write permission restricted the web server running as www-data cannot write to any of those files. This way there is no need to chown/chrgp any of the files. That keeps attacks against the web server from being able to modify any files on disk. If the web server needs to be able to store files to disk such as for photo uploads then those are typically done in a single directory. I would at installation time using root chgrp the upload directory to the www-data user so that files could be stored there. That wouldn't need to be changed upon every update. One setup would be enough. That is pretty typical because the files on disk are usually required to be persistent across web updates. Typically I see those in a shared directory and new code updates using symlinks to make the directory appear in the versioned code area. As I said there are many good ways to do things. That is simply one such scheme. And as I mentioned it conflicts with the requirements of many of the popular PHP setups. You must apply your own judgement on the tradeoff between ease and security. Bob
