On 06/19/2014 01:31 PM, Wouter Thielen wrote: > Hi Bob, > > Sorry for my late reply regarding this thread. > > 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. > > You said: > "I always recommend to use the lowest priviledge needed to perform a task." > > 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". 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. > > 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. > > 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. > > Thanks for your consideration. > > Wouter > > > On Thu, May 15, 2014 at 3:24 PM, Bob Proulx <b...@proulx.com> wrote: > >> Wouter Thielen wrote: >>> Here is a very common usecase: >>> sudo chgrp www-data dir >>> in a deployment script. >> >> Hmm... Why are you often changing files to www-data? That is usually >> the process id that owns the web server process. Usually running >> apache or nginx or other web process. It is chosen specifically to >> avoid having it have the ability to write any files on disk as a >> security layer. Therefore you would normally never have files on disk >> owned by www-data. That is the security layer that the unique id >> provides. May I ask what you are doing that needs this? Perhaps we >> would suggest an alternative configuration. >> >> If you want to store files from the web server then of course that >> directory needs to be writable by the www-data user. But that is >> usually a one time setup change and then never again and it sounds >> like you are doing more than this and often. I fear that you are >> changing files served by a web browser to be the www-data user and >> that would allow a crack in the web server process to write to the >> DocumentRoot. That would be bad. Although many PHP projects require >> just that type of configuration which sets them up for many security >> problems. For example Wordpress is notorious for security breaches >> because of such configurations. >> >>> I have always used "sudo" with this because I didn't know why I was >> getting >>> an operation permitted error when doing so. Until I found out that if the >>> effective user is a member of the target group www-data, the sudo isn't >>> needed. >> >> Since sudo gives you root permission (in the simple configuration) >> that is the highest priviledge. I always recommend to use the lowest >> priviledge needed to perform a task. It is safer. But few people >> care about safety. I often see recommendations in blogs and articles >> that say to use root because that is the simplest way to grab the >> biggest hammer in the toolbox and pound away. That isn't so nice. >> But people do it all of the time anyway. >> >> For example: You mention www-data so perhaps you are using Debian? In >> Debian /usr/local is group 'staff' so a member of group staff can work >> there without needing sudo. That is very nice. Unfortunately other >> systems don't set that up by default. >> >>> The Wikipedia clearly says that: >>> >>> The *chgrp* (from *ch*ange *gr*ou*p*) >>> command<http://en.wikipedia.org/wiki/Command_(computing)> may >>> be used by unprivileged >>> <http://en.wikipedia.org/wiki/Privilege_(Computing)> users >>> on Unix-like <http://en.wikipedia.org/wiki/Unix-like> systems to change >> the >>> group associated with a file system object (such as a file, directory, or >>> link) *to one of which they are a member*. >>> >>> I am wondering why the chgrp manpage or info pages do not mention >> anything >>> about that. It would be very helpful to add that piece of very crucial >>> information to the manpage/info pages. >> >> What capabilities the user has and can do with chown, chgrp, chmod, >> and so forth is a system dependent system policy. The GNU coreutils >> have traditionally been portable to many different operating systems. >> The list of operating systems goes on and on. Different operating >> systems have different requirements. It is rather difficult to >> document all of the idiosyncratic behavior of every operating system. >> Generally when operating system policy is not documented by the >> coreutils that is the reason why. >> >> I am not saying that it wouldn't be useful to somehow document this >> system dependent behavior. You asked why it wasn't and that is what I >> am answering. If you have suggestions or patches to the documentation >> that improve the existing state that is always appreciated. But note >> that writing good documentation is harder than it sounds. Would you >> like to suggest an improvement to the docs? >> >> Bob
The variation on some systems where users can give away files is discussed at the "APPLICATION USAGE" and "RATIONALE" sections of: http://pubs.opengroup.org/onlinepubs/9699919799/functions/chown.html We should mention this _portable_ behavior in the info doc at least for chown and chgrp thanks, Pádraig