AFAIK the only distribution which runs CUPS as a non-root user is
Ubuntu. All CUPS backends which require root access, as for example lpd,
run SUID root. This way Ubuntu minimizes the amount of software pieces
which run as root. To avoid arbitrary users to start the SUID root lpd
backend manually, it is only executable for user root and group lp, not
for others:
-rwsr-xr-- 2 root lp 16712 2006-10-09 18:56 lpd
Also cups-pdf, a backend which drops files in the home directory of the
user who sent the job originally works with these ownerships/permissions
(I have tested it).
So there is no problem with a CUPS backend needing root access on any
distribution.
The "make install" only needs to do the appropriate of these two:
CUPS runs as root:
chown root /usr/lib/cups/backend/hpfax
chmod 0700 /usr/lib/cups/backend/hpfax
CUPS runs as non-root:
chown root.lp /usr/lib/cups/backend/hpfax
chmod 4750 /usr/lib/cups/backend/hpfax
To check which of the two versions have to be used one can check whether
- A running cupsd runs as root or not
- The distro is Ubuntu
- Simply overtake permissions and ownerships of lpd backend
Till
dwelch91 wrote:
> Hello, Till:
>
> What you describe is how faxing originally worked. However, there are
> problems with permissions that I could never work around after a large
> amount of effort.
>
> On some systems, CUPS (and thus hpfax:) run as lpadmin, and one some
> systems, it runs as root. (I cannot remember now which systems are
> which). On those systems that run CUPS as root, writing the data into
> each user's directory as you suggest works well. However, on systems
> that run CUPS as lpadmin, this is not possible. So, this new system of
> handing the data off the hpssd as an intermediary was developed to get
> around this issue. I agree that this solution is not ideal, but it is
> the only solution I could make work on all distros.
>
> As it stands right now, fax jobs should not be lost if sendfax is not
> running, they get queued up by hpssd waiting for a (correct) sendfax to
> be run. As long as the QSocketNotifier mechanism works, this is the case.
>
> My plan at this point is to look into a polled solution. This would
> require a fair amount of code change, but I should be able to get a
> solution that works fairly directly. Of course, figuring out the issue
> with QSocketNotifier would be the best solution. We will continue to
> work with Phil to see if any headway can be made in that direction.
>
> I have further feedback below.
>
> Thanks,
>
> Don
>
>
>
> On 10/30/06, *Till Kamppeter* <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> Hi,
>
> two weeks ago (before the Printing Summit in Lexington) I have observed
> that faxing with HPLIP 1.6.7, 1.6.9, and 1.6.10 works without problem
> under Mandriva 2007 (released three weeks ago) and does not work at all
> with Ubuntu Edgy/6.10 (released last week). Under Ubuntu Dapper/6.06
> faxing works, too.
>
> After some discussion with Donald Welch and Phil Thompson we found out
> that on the transition from PyQt 3.15 to 3.16 a new bug was introduced
> which broke inter-process communication (IPC) between hpssd and
> hp-sendfax (a fax job sent into the "hpfax:/..." queue is forwarded to
> the hp-sendfax of the user who sent the job by hpssd and supposed to
> stay in the CUPS queue when hp-sendfax is not running in the sender's
> account). From PyQt 3.16 on Fax jobs sent out by hpssd seem to run into
> a black hole instead of being picked up by hp-sendfax.
>
> Debugging this is very complicated for end users and even experienced
> system administrators:
>
> - It is difficult to find out the version numbers of PyQt and SIP as
> some distros ship them in the kdebindings package and also if they are
> in separate packages the package names are not the same.
>
>
> Our utility hp-check provides this information.
>
>
> - One cannot easily find out how to bring a Python program into debug
> logging mode (someome of you told it to me and I saved this information
> in a file, but whenever I need it I am looking up this file).
>
>
> All of our utilities provide --help and they all (with the exception of
> hp-sendfax, which uses --gg) use -g for debugging.
>
> - Running HPLIP and CUPS normally no footprints of the faxing process
> appear in any log file.
>
>
> The output of hpijs and hpfax are recorded in the CUPS error log like
> any other print job.
>
>
> In addition the PyQt guys did not propose any fix or at least a
> workaround yet.
>
>
> We are doing additional testing to further narrow down the possible
> suspects for the defect. I'll let you know what we find.
>
>
> So every Edgy user and also every user trying out KDE 3.5.5 on other
> distros has broken fax with HPLIP now.
>
> To make faxing with HPLIP more robust and to make admin's life easier, I
> suggest the passing of the fax via hot folder:
>
> Every user has a hot folder named ~/hpfax/ in his home directory
> (auto-created if needed).
>
>
>
> This is almost exactly the way faxing used to work (but, as I said above
> it didn't work on all distros. We didn't know that until we tested it
> extensively). I also tried using the /tmp and /var folders with similar
> failed results.
>
> When a user sends a job into the fax queue, the hpijs driver converts
> the job into fax G3 format and the hpfax CUPS backend drops the fax G3
> file in the user's hot folder (hot folder created by hpfax backend if
> needed). hpfax should be fairly the same code as the cups-pdf backend
> available as free software here (and available as Debian package in
> Ubuntu Edgy):
>
> http://www.physik.uni-wuerzburg.de/~vrbehr/cups-pdf/
>
> On Ubuntu Edgy (CUPS runs as "cupsys" user) this backend runs SUID root
> so that it has root rights to create directories and files in the user's
> home directory. On other distros (CUPS runs as root) it is enough to
> give 0700 permissions to the backend.
>
> As soon as the user runs hp-sendfax, hp-sendfax checks the hot folder
> regularly (for example every 3 sec) and shows every file in the list of
> files to be faxed, but does not delete or modify any file in the hot
> folder.
>
>
> This way of polling is probably the best idea as a workaround for this
> problem.
>
>
> If the user uses the "add to list" function, the chosen file is
> simply put into the fax queue and the converted file appears
> automatically in the list as soon as CUPS has converted it and the hpfax
> backend has dropped the result in the hot folder. If the user finally
> sends his fax, every successfully faxed file gets deleted from the hot
> folder. If the user closes hp-sendfax without faxing, the files stay in
> the hot folder and can be faxed by calling hp-sendfax later.
>
> Advantages:
>
> - CUPS queue for faxing is not blocked when the user who has sent the
> first job has no hp-sendfax running, as fax jobs leave the CUPS queue
> immediately.
>
>
> This is the way it works currently.
>
> - CUPS's filter work to get a job converted to G3 can easily be
> monitored by watching files appearing in the hot folder and by opening
> them with Konqueror (Konqueror uses KDE's fax program to display G3
> files).
>
>
> I agree, this would be a nice addition. Perhaps hpssd can queue the
> files instead of hpfax:, as it runs under a more consistent user.
>
> - hp-sendfax can be started before or after sending the fax job, nothing
> gets lost due to hp-sendfax not running.
>
> - hp-sendfax can be closed without faxing and the fax jobs do not get
> lost. They can be faxed later.
>
>
> This would be a nice feature. However, I modeled hp-sendfax after
> printing - if you press cancel on the printer, the print job is lost.
> Similarly, if you press cancel in hp-sendfax, the fax job is lost.
>
> - The data flow is much more clear to users and admins, so debugging is
> easier. Also maintaining it secure is probably easier then.
>
>
> All good goals. I agree that the current fax architecture is not ideal,
> but it did evolve through the necessity of making it work on all
> platforms/distros and with as much usability as I could manage. Clearly,
> more improvement is needed. However, I do not feel that the current PyQt
> related bug necessitates a full re-write.
>
> WDYT about that?
>
> Till
>
>
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
HPLIP-Devel mailing list
HPLIP-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hplip-devel
