Bug#711848: cups-client: lp and lpr print the document on a wrong printer
Hi,
On 2013-06-10 13:27:47 +0200, Didier 'OdyX' Raboud wrote:
> Can you provide the access rights of .cups/lpoptions?
>
> $ ls -l ~/.cups/lpoptions
ypig:~> ls -l ~/.cups/lpoptions
-rw-r--r-- 1 vlefevre vlefevre 74 2013-02-01 16:29:37 /home/vlefevre/.cups/lpoptions
I've also done a strace diff between:
(1) strace -o str1.out -f lpr lineskip.pdf
(2) strace -o str2.out -f lpr -P lip-multi-3 lineskip.pdf
in this order. I can notice in particular:
[...]
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=117407552, ...}) = 0
mmap(NULL, 117407552, PROT_READ, MAP_PRIVATE, 3, 0) = hex
close(3) = 0
futex(hex, FUTEX_WAKE_PRIVATE, 2147483647) = 0
geteuid() = 1000
getuid() = 1000
getegid() = 1000
getgid() = 1000
-access("lineskip.pdf", R_OK) = 0
-open("/home/vlefevre/.cups/lpoptions", O_RDONLY) = 3
-fcntl(3, F_GETFD) = 0
-fcntl(3, F_SETFD, FD_CLOEXEC) = 0
-read(3, "Dest lip-multi-3 ColorModel=Gray"..., 4096) = 74
-close(3) = 0
open("/home/vlefevre/.cups/client.conf", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/etc/cups/client.conf", O_RDONLY) = 3
fcntl(3, F_GETFD) = 0
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
read(3, "#\n#\n# Sample client configurat"..., 4096) = 2224
read(3, "", 4096) = 0
close(3) = 0
open("/home/vlefevre/.cups/client.conf", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/etc/cups/client.conf", O_RDONLY) = 3
fcntl(3, F_GETFD) = 0
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
read(3, "#\n#\n# Sample client configurat"..., 4096) = 2224
read(3, "", 4096) = 0
close(3) = 0
rt_sigaction(SIGPIPE, {SIG_IGN, [], SA_RESTORER, hex}, NULL, 8) = 0
access("/etc/gcrypt/fips_enabled", F_OK) = -1 ENOENT (No such file or directory)
open("/proc/sys/crypto/fips_enabled", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
[...]
-getrusage(RUSAGE_SELF, {ru_utime={0, 4000}, ru_stime={0, 8000}, ...}) = 0
-times({tms_utime=0, tms_stime=0, tms_cutime=0, tms_cstime=0}) = 1718347093
-getrusage(RUSAGE_SELF, {ru_utime={0, 4000}, ru_stime={0, 8000}, ...}) = 0
-times({tms_utime=0, tms_stime=0, tms_cutime=0, tms_cstime=0}) = 1718347093
-open("/etc/cups/lpoptions", O_RDONLY) = -1 ENOENT (No such file or directory)
-open("/home/vlefevre/.cups/lpoptions", O_RDONLY) = 5
-fcntl(5, F_GETFD) = 0
-fcntl(5, F_SETFD, FD_CLOEXEC) = 0
-read(5, "Dest lip-multi-3 ColorModel=Gray"..., 4096) = 74
+recvfrom(4, "[...]", 5, 0, NULL, NULL) = 5
+recvfrom(4, "[...]"..., 784, 0, NULL, NULL) = 784
+getrusage(RUSAGE_SELF, {ru_utime={0, 0}, ru_stime={0, 12000}, ...}) = 0
+times({tms_utime=0, tms_stime=1, tms_cutime=0, tms_cstime=0}) = 1718362144
+getrusage(RUSAGE_SELF, {ru_utime={0, 0}, ru_stime={0, 12000}, ...}) = 0
+times({tms_utime=0, tms_stime=1, tms_cutime=0, tms_cstime=0}) = 1718362144
+open("/dev/tty", O_RDONLY) = 5
+ioctl(5, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
+ioctl(5, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
+ioctl(5, SNDCTL_TMR_CONTINUE or TCSETSF, {B38400 opost -isig -icanon -echo ...}) = 0
+ioctl(5, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost -isig -icanon -echo ...}) = 0
+fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 9), ...}) = 0
+mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = hex
+write(1, "Password for vlefevre on lip-pri"..., 60) = 60
[...]
I won't send you the strace as it contains the password and maybe
other private information, but /home/vlefevre/.cups/lpoptions is
read twice (successfully) in case (1) and none in case (2).
In case (1), the file was sent to lip-multi-1 instead of lipucb-mono-1.
In case (2), the file was sent to lip-multi-3 as expected.
> It's fine for you to disagree, but the list [0] is considered as
> authoritative on bugs severities. If you think this list should be
> changed, please start a discussion on a proper forum; probably a bug
> on debian-policy as it's 1.1 chapter defines what bug corresponds to
> a "serious" severity, which is completed by the Release Team's RC
> policy [1]. Under the current rules, this bug doesn't fit the
> defintion of serious in my reading.
[1] also says:
in the maintainer's opinion, makes the package unsuitable
for release
(these issues are "serious" severity)
You could also consider that due to security concerns, the package
is unsuitable for release.
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Reply to: