[FreeNX-kNX] FreeNX 0.6.0.99 snapshot with full printing support and some bugs fixed

[Kurt Pfeifle]

On Thursday 25 January 2007 19:13, Fabian Franz wrote:
> > >  * Note: You might need to do: chmod 755
> > /usr/lib/cups/backend/{ipp,http}
> > > 
> > > -> This is just in general. While testing I found out that debian set 
> > > /usr/lib/cups/backend/ipp and http to 700 with no reason whatsforever. 
> > > I guess this is just a bug and the chmod did fix it for me.  
> > 
> > No. It's part of a feature. CUPS will automatically run backends that 
> > are set to 700 as root, and will run all other backends as user "lp"
> > (or whatever the user is). {So for example if you are using a CUPS 
> > "pdf:/"-backend as a PDF distiller server for the network, that backend 
> > should be able to write its results to users' homedirs, it must have 
> > extended privileges.) The ipp:// backend needs access to the certs
> > files/dirs. The lpdf:// backend needs access to source ports 721-731,
> > because RFC "standard" for LPD expects its clients to come from these
> > ports, otherwise it refuses connections/printing.
> 
> Kurt as always you are a mine of gold when it comes to CUPS knowledge.
> 
> > chmod-ing {http,ipp} takes away the ability for those backends to
> > run as root. This may be fine for all FreeNX-related tasks, but may
> > meet occasions where it disturbs other purposes...
> 
> Yes, sure. But why can't the mask be: 744 this way one could copy the 
> ipp and http files. I guess just the executing part is the problem or 
> not?  
> 
> Either way I find that this method is quite a hack - to rely on the 
> mask of the file to depend which user to run on.

It came about because in 1.2 CUPS abolished support for its "RunAsUser" 
directive in 1.1 (I believe Ubuntu Dapper has it patched in again), 
because it led to too many problems, without really giving a security
gain.

> However I can see  
> that a config file is not as flexible.  
> 
> I therefore propose to just cp the file (as root) to a regular file 
> named ipp_nx and add a config option: CUPS_IPP_BACKEND=ipp_nx. Would 
> this pose a problem?  

I can't think of any, right now. It was my first idea too (without the
underscore, and in reverse :-)  ).

One little "problem" is still this: upon startup, CUPS 1.1 runs each 
executable and each backend with zero arguments, listens to their
output (which is required to follow a certain convention), and then
"registers" available backends and filters (to build filtering chains
and to allow "lpadmin" etc. to use only registered backends during
printer installation).

A copied nxipp:// backend will just output the same line twice. Wait...
The http:// backend is only a symlink to ipp:// one, and it also 
outputs its called name. So it may even work for a copy "nxipp" 
perfectly, and the copy would possibly output a different line, 
like:

  'network nxipp "Unknown" "Internet Printing Protocol (nxipp)"'

(I haven't tried).