Description of Problem: While trying to set up efax for remote faxing, I found that remote print jobs end up creating cf* and df* files that have permissions 660 but not owned bygroup "lp." Locally printed jobs DO create the files group-owned by "lp". Since efax works as a filter, and filters run with a gid of "lp", then efax will fail for remote jobs where local jobs will work. It's very odd that the group ownership of cf* and df* files differ based on where the jobs originate. It seems that readfile(), if not the whole daemon, should run with a gid of lp so that the files are created consistently. I am running with version lpr-0.50.5-1, the latest from Redhat 6.2's errata. Version-Release number of selected component (if applicable): lpr-0.50.5-1, the latest listed in the errata. How Reproducible: Very reproducible Steps to Reproduce: 1. Create a print queue -- make the lp /dev/null (no need to waste paper), and create a spool directory just for this queue. Create a log file, too. 2. Create a print filter that lists the files in the above spool directory, and set the input filter of this new queue to be this filter. 3. On another box, create a remote print queue that points to this queue. 4. Try to print locally, then try to print remotely. 5. Take a look at the log file, and you should see two listings; the local attempt to print will show cf* and df* files having the group ownership of "lp", where the remote attempt to print will have the log-in groups of the user-ids. Actual Results: explained above. Expected Results: explained above. Additional Information: The version of efax I am running is from Redhat: efax-0.9-4. If you follow the steps to reproduce, there is no need to install efax.
Additional notes: doforkuser, which is called to run the filter, explicitly sets the effective group to "lp." The permissions for lpd, as installed, are 744, root:root.
Thanks for reporting this. I can reproduce it.
This never got high enough priority to fix.