`lpoptions -o <PrinterSpecificOption>=<value> behavior inconsistent with man page

[dmullis]

Describe the bug
If running as root, strace reveals lpoptions behavior inconsistent with the man page.

To Reproduce
Steps to reproduce the behavior:

Observe that in base Ubuntu installation, no file /etc/cups/lpoptions exists.

$ ls -l /etc/cups/lpoptions
ls: cannot access '/etc/cups/lpoptions': No such file or directory

Run:

strace -f -e trace=file lpoptions -o DefaultOutputOrder=Reverse |& grep -v lib/x86_64-linux-gnu/lib`

Output excerpt:

...
openat(AT_FDCWD, "/etc/cups/lpoptions", O_RDONLY) = 4
openat(AT_FDCWD, "/root/.cups/lpoptions", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/localtime", O_RDONLY|O_CLOEXEC) = 4
access("/root/.cups", F_OK)             = 0
openat(AT_FDCWD, "/root/.cups/lpoptions", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4
...

Expected behavior
Current man page of lpoptions reads:

When run by the root user, lpoptions gets and sets default options and instances for all users in the /etc/cups/lpoptions file. Otherwise, the per-user defaults are managed in the ~/.cups/lpoptions file.

The above text is unchanged from that in the lpoptions man page from Ubuntu apt package cups-client.

Note that following the failed attempt to open in read-only mode the non-existent /etc/cups/lpoptions, no write or other access is attempted. Rather, /root/.cups/lpoptions is written into.

System Information:

• Ubuntu 22.04
• CUPS Version: 2.3.1-9ubuntu1.2

[michaelrsweet]

You actually want to report this in the CUPS 2.x project...

[dmullis]

Above is perhaps related to a more general Ubuntu 20.04.6 distro packaging issue: man lpadmin appears same as current at openprinting.github.io, whereas lpadmin -h specifies a different order of CLI arguments.

$ lpadmin -h
lpadmin: Expected hostname after "-h" option.
Usage: lpadmin [options] -d destination
       lpadmin [options] -p destination
       lpadmin [options] -p destination -c class
       lpadmin [options] -p destination -r class
       lpadmin [options] -x destination
Options:
...

Yet both files are provided by the same .deb package:

$ dpkg --listfiles cups-client
...
/usr/sbin/lpadmin
...
/usr/share/man/man8/lpadmin.8.gz
...

$ apt show cups-client
Package: cups-client
Version: 2.3.1-9ubuntu1.2
...

[michaelrsweet]

@tillkamppeter Does Ubuntu patch the default lpoptions behavior?

[tillkamppeter]

I have checked and

• I get the same behavior as the original poster gets, I am using Ubuntu 23.04 Lunar
• I cannot find any patch affecting lpoptions nor any related remark in debian/changelog.

[tillkamppeter]

The code responsible for deciding into which file to write the option settings of lpoptions is in the cupsSetDests() function in cups/dest.c (libcups):

 /*
  * Figure out which file to write to...
  */

  snprintf(filename, sizeof(filename), "%s/lpoptions", cg->cups_serverroot);

  if (cg->home)
  {
   /*
    * Create ~/.cups subdirectory...
    */

#if _WIN32
    snprintf(filename, sizeof(filename), "%s/AppData/Local/cups", cg->home);
#else
    snprintf(filename, sizeof(filename), "%s/.cups", cg->home);
#endif // _WIN32
    if (access(filename, 0))
      mkdir(filename, 0700);

#if _WIN32
    snprintf(filename, sizeof(filename), "%s/AppData/Local/cups/lpoptions", cg->home);
#else
    snprintf(filename, sizeof(filename), "%s/.cups/lpoptions", cg->home);
#endif // _WIN32
  }

 /*
  * Try to open the file...
  */

  if ((fp = fopen(filename, "w")) == NULL)
  {
    cupsFreeDests(num_temps, temps);
    return (-1);
  }

Here is nothing like if (getuid() == 0) ... or similar to tell whether the data should be saved in /etc/cups/lpoptions or in ~/.cups/lpoptions. The decision is done by if (cg->home) ... and this is also filled for root (with /root). This code snippet is not patched in the Debian/Ubuntu packages, it is the same as upstream.

[zdohnal]

This code snippet is not patched in the Debian/Ubuntu packages, it is the same as upstream.

This code snippet is really the same as upstream, but CUPS 2.3.1 upstream :) .

This is fixed in 2.4.3 and it's dupe of #454 - @dmullis please contact your support for backporting the patch or upgrade to CUPS 2.4.3 in case you want this behavior fixed for you.