checksetup.pl, if you have no webservergroup supplied in localconfig, sets the permissions on the data directory to drwxrwxrwt - that is, world writable with the sticky bit set. The stated purpose of the sticky bit is that any given user can only delete files that they created. However, it also appears to restrict you from moving/renaming files in that directory as well, if you're not the owner of the directory. The Param() function attempts to build a data/params file if there are missing params in it by merging the defaults with the existing params file and writing it to a new file, then renaming the new file to the old filename. I've duplicated this both on Mac OS X (darwin) and on Red Hat 6.2 (linux) This especially hurts a new install because any CGI in Bugzilla will crash with a 500 Server Error because the data/params file doesn't exist and it can't create one. On an existing install, trying to run editparams.cgi silently fails to update the changes you made (and doesn't tell you that either)

making this a release blocker since it's outright broken. I don't like the idea of making the directory world-writable without sticky, but that does fix the problem...

Maybe we could have a directory inside data for the params to be stored and have sticky off on that. That way data can still be sticky, but the params can be deleted and replaced.

See also bug 122110

Comment on attachment 76501 [details] [diff] [review] patch v1: turns off sticky bit for data directory r= justdave

unfortunate side effect of running it without access to the webservergroup.

Comment on attachment 76501 [details] [diff] [review] patch v1: turns off sticky bit for data directory r=bbaetz Note that defparams.pl::WriteParams does chmod 0777 "data", after trying to create the data dir for you, then does chmod 0666 "data/params", so this isn't safe even with a webserver group - the params file is world writable. Should I file a separate bug on that, or do you want to handle it here?

-> patch author

Myk, this is ready for checkin.

writing the params should not attempt to create the data directory at all. It should fail (and say so) if the data directory doesn't exist, because it means the admin never ran checksetup.pl. File a separate bug on that. As for the chmod 666 on the params file, that's irrelevant, because if world read/execute access isn't given to the data directory (as is the case if you have webservergroup set) then no one can get into the directory to see the world-writable file anyway. Though for consistancy that should probably be dealt with, too. That can probably go in the above new bug if it's worth dealing with.

No, this is still a bug. Filed bug 134575.

Checking in checksetup.pl; /cvsroot/mozilla/webtools/bugzilla/checksetup.pl,v <-- checksetup.pl new revision: 1.134; previous revision: 1.133 done

*** Bug 118082 has been marked as a duplicate of this bug. ***