1. Forum
  2. Usenet
  3. LINUX.DEBIAN.USER

  • Printing Problem with CUPS

    From Christoph Pleger@21:1/5 to All on Fri Apr 11 14:30:01 2025
    Hello,

    I have a strange problem with CUPS and hope that someone can help me
    with the solution.

    "Strange", in this case, means that I have two machines, both running
    Debian 12 and the corresponding versions of cups and cups-browsed.
    On one of these machines, I can print as any user, while on the other
    computer it works only as root. In both cases, printing is to take
    place on a remote printer whose information is received via IPP
    broadcast from cups-browsed.

    I have edited the source code of cups a little to get a some more
    more detailed information about the problem (the actual code
    only gives a meaningless message “The print file cannot be opened:
    Permission denied") and then found out the following:

    The “print file” is a temporary file in /tmp, has the UID 0 and
    the GID 7 (belongs to the system user lp) and the access rights 600, so
    it can only be written or read by root. The process that
    tries to access the file has the somewhat strange name ipp://$RemoteHost:$RemotePort/printers/$Printer .

    The decisive difference between the two computers is:

    On the computer where printing works as expected, the
    process with the strange name is executed under the effective UID 0,
    while on the other computer, the effective UID is the UID of the user
    who wants to print something. In the latter case, the “print file”,
    which can only be accessed by root, can of course not be opened.

    Does anyone have an idea why the strangely named process runs with root
    rights on one machine, but not on the other?

    Greetings
    Christoph


    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEHeqYcooFjlnR4zwFcOXIip7d3fEFAmf5CBEACgkQcOXIip7d 3fEDvxAAqQCMjbt7mBdl8ub8bD8kd4K9ADFuOjcjwJDvlPpP9FSiizueaP1FxGNc +aCV3CuIcmHIS5nrDHvpUaaFa4jyTq2Kk4+zyfPBMbS5c0sUv6Zdip24VeM69h86 Bdx5U9oEuCYPsKhY+yMcau4T5j56l4CQ0WoUQFiDJ8bksgN13gu3rLfCyfj9f+fC d/ngJW5nPSZzCtdgG/YFxVtkxu+C6X4yrvOqNL1yQW+7MhADnEF0ZmEZR9Sus79N w0moWm6m2WuqWPsiYRBJOY6ZAIzGPFEsME+e/L1jR21IwlgC8kYqUJKuC8RI+H0g OCP7spbIXtD6Mjs1OXDQFTLKeFjpRGVLsrbpbFeApOK+Go+rcP+q9iFFTNGGNjMC XIb/okKHIQ3JfO33wOwAQ+z2fiqEY+EJWzQuEVoyvdYUT7/FkMlJgFNKtwy7jdiU rgS3aqc+m4Air/WKYsdXiSO04svTAZ9LPrrNwQGRFjdHsgg0n11Fx+B+1BtxJCC/ I0Og1HwB5+WeJTiS4U9kZRLi2zMxoFWEk+H3rvnnLaJDRx4/ULffmX3ZMqqyxhAV GwS+u1ddCgoABi1LdH56xfWGCfxR0T8RMlTMIUdxIk7WsJzeu8iWJ0KdxoiPscsr Gq1fsQeVAgA3wVemiEU3nzaeq9b3aze6nlk8nDufZG8+B/dbnak=
    =EQRP
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Greg Wooledge@21:1/5 to Christoph Pleger on Fri Apr 11 14:30:01 2025
    On Fri, Apr 11, 2025 at 14:16:17 +0200, Christoph Pleger wrote:
    I have edited the source code of cups a little to get a some more
    more detailed information about the problem (the actual code
    only gives a meaningless message “The print file cannot be opened: Permission denied") and then found out the following:

    The “print file” is a temporary file in /tmp, has the UID 0 and
    the GID 7 (belongs to the system user lp) and the access rights 600, so
    it can only be written or read by root.

    Check the permissions of /tmp on both systems? ls -ld /tmp

    It's the first thing that comes to mind, even though I can't think of
    a specific misconfiguration that would cause a temp file to have
    the wrong owner.

    If it's not obvious from the ls -ld output, then look at the mount
    options and file system type. If you've done something extremely
    unusual like mounting a VFAT file system as /tmp, well, that might
    do it too.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Hans@21:1/5 to All on Fri Apr 11 14:50:01 2025
    Without any checks, my first thing would be, to check in both computers if any of the executables related to cups might have different rights settings.

    Especially the executable, which creates the file in /tmp. A file which is created mostly gets the ownership and posessions of the creatorbinary (father- child-principle).

    The other thing, which maybe show more informations: If you are able to print from the commandline, then "strace" might be a good help, just to see, when and wo´ho is creating the tempfile.

    As you have one working system and another "alien" working system, you might be able to compare both things and find the different behaviour and step, when it happens.

    Maybe so you get more data, to get closer to the cause.

    Yeah, maybe help not much, but so I would do.

    Best

    Hans

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Greg Wooledge@21:1/5 to Hans on Fri Apr 11 15:20:01 2025
    On Fri, Apr 11, 2025 at 14:41:04 +0200, Hans wrote:
    Without any checks, my first thing would be, to check in both computers if any
    of the executables related to cups might have different rights settings.

    Especially the executable, which creates the file in /tmp. A file which is created mostly gets the ownership and posessions of the creatorbinary (father-
    child-principle).

    Not exactly. A file inherits ownership from the effective UID under
    which the process is running, which is usually not the same as the owner
    of the process's on-disk executable file(s). Usually the file will be
    owned by root, but the effective UID of the running process will be set
    by the init configuration file (systemd unit or sysv-rc script).

    However, if an executable file has the setuid or setgid permission bit(s)
    set, then the effective UID and/or GID of the process will be set to
    match the file's owner and/or group.

    So, to add to the list of things that you can check:

    * Broken permissions (added or missing setuid or setgid) on any of
    the CUPS binaries.

    * Invalid UID or GID of a named system account under which any of these
    programs is executed, or a missing system account entry.

    * Broken systemd or sysv-rc init files.

    And, as I mentioned before:

    * Broken permissions on the /tmp directory (after mounting, if it's a
    separate file system).

    * Invalid file system type or mount options on the /tmp file system,
    if it's a separate file system.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Christoph Pleger@21:1/5 to All on Fri Apr 11 17:00:02 2025
    So, to add to the list of things that you can check:

    * Broken permissions (added or missing setuid or setgid) on any of
    the CUPS binaries.

    * Invalid UID or GID of a named system account under which any of these
    programs is executed, or a missing system account entry.

    A comparison of the lists of setuid executables does not show any
    difference that is possibly relevant for cups ...


    * Broken permissions on the /tmp directory (after mounting, if it's a
    separate file system).

    * Invalid file system type or mount options on the /tmp file system,
    if it's a separate file system.

    Both /tmp are tmpfs, owner root, group root, permissions drwxrwxrwt .

    Honestly, I am completely at my wit's end where this sh*t comes from
    ...

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEHeqYcooFjlnR4zwFcOXIip7d3fEFAmf5LPYACgkQcOXIip7d 3fFL6g/+KIQKmFcFwhtAgalY44LXT9LLF6RQGLDevO1n9HwJd0kR26RQ+esoIrV3 qO2ugsZscpRqQpCrNfPTjVUCgXeH96p9QOOtW1y83TOCX5aartHwhbv51m4OvScI ROJkiWGW5JRpd72mOkoESetwU4E32X4Thy7pPYSuDIfxMGoHnzomchYvORIesmUm rxr9Rguwm73Xrr2yE7agoNm9MgJsczHDaHluH5rHUxgKE+n9k+GxcSZkVd4DnGxf +gAk2AHKvtlbEheggAyw+qszqXCM0c4KFvAn3DP6pa7cveGPaabl7jQBjumUlaT5 hKjAvuTNgIyoOPl9yol4wLM8oVsaG6JTYooFtQO56//izD3wpJfuwq5f/GPx4nVq b0+vNcj5bfg2gbcippI3Rp+BxYrqJXHfNcl5isBwvNpaadlWT5jXQ8cUHDdblkDf pN8zy1N8tMWsEBQPa9bEp0LWeMOn6dQhoYb7Qt9RnRRzz+8VySmnu5/p6t1iJ+9/ I9GI0pGX+uiDZqlcCSubTThJpqfYAET6+dfwJVyBK6fq12bEyZKS99MtyozG9DKj iKoylRu/a/FUtPh+W1uRGZOqhmGmhLoqvFiUJOjvH+LX6eXcDuWMxB0h6LyW9dhe w1jkCVQbpT4UV7hS6Vjk1HkYDa6uTxksn/BdYk+Hr0MalfNSGec=
    =PyOo
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From songbird@21:1/5 to Christoph Pleger on Sat Apr 12 13:00:02 2025
    Christoph Pleger wrote:
    Hello,

    I have a strange problem with CUPS and hope that someone can help me
    with the solution.
    ...
    Does anyone have an idea why the strangely named process runs with root rights on one machine, but not on the other?

    this is my guess...

    purge the problem installation of cups and reinstall.

    i suspect you may have done some kind of update or removal
    of a suggested component or something like that.


    songbird

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Klaus Singvogel@21:1/5 to Christoph Pleger on Sat Apr 12 17:20:01 2025
    Christoph Pleger wrote:
    I have edited the source code of cups a little to get a some more
    more detailed information about the problem (the actual code
    only gives a meaningless message “The print file cannot be opened: Permission denied") and then found out the following:

    Enabling the CUPS error log should be good enough, instead of modifying the source code. A howto for enabling it, can be found here:

    https://wiki.debian.org/CUPSDebugging


    The “print file” is a temporary file in /tmp, has the UID 0 and
    the GID 7 (belongs to the system user lp) and the access rights 600, so
    it can only be written or read by root. The process that
    tries to access the file has the somewhat strange name ipp://$RemoteHost:$RemotePort/printers/$Printer .

    IPP is the daemon, which receives the print jobs. I think this is fine.

    Does anyone have an idea why the strangely named process runs with root rights on one machine, but not on the other?

    As said, follow this page for debugging CUPS: https://wiki.debian.org/CUPSDebugging

    Best regards,
    Klaus.
    --
    Klaus Singvogel
    GnuPG-Key-ID: 1024R/5068792D 1994-06-27

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)