Zaar Hai asked me to comment on this. I quote from my comments in the config.h file for pwauth:
/* It is generally sensible to restrict what users can run pwauth. [...] * * There are two ways to do this. First, you can compile in the uid numbers * that are allowed to run this program, by listing them on the SERVER_UID * variable below. At runtime, pwauth will check that the uid of the user * that invoked it is on this list. [...] * * The second option is to create a special group, called something like * "pwauth" for user id's that are allowed to run pwauth. To do this, you * should compile pwauth with the SERVER_UIDS variable UNDEFINED. This will * disable the runtime uid check. Then, when you install the pwauth program, * set it's group ownership to the "pwauth" group, and permit it so that only * the owner and the group can run it. Do not permit it to be executable to * others. This has the advantage of not requiring a recompile if you want * to change the uid list. */ So Paul's suggestion is basically to use the second option instead of the first. If the www-data group normally contains only the www-data user then this would normally be equivalent to the current configuration except that other uids could be added without rebuilding the package, which seems like a good idea in a general purpose distribution. My one point of concern, speaking as a person unfamiliar with the details of debian, would be about the www-data group's other uses. If www-data is used for a lot of things other than determining who may run pwauth, then people might add miscellaneous things to www-data without knowing that they are loosening the security on pwauth. If you're going to be using a group to control access to pwauth, then that should probably be the only purpose of the group, so you might want to create a group named something like www-pwauth which normally contains only the www-data user. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
