Hendrik Boom <hendrik@???> writes:

[...]

>>     Since group has no permission and owner has all, only the owner
>> should matter. But the group s bit, AFAIR is something which
>> disallows overwriting a file owned by someone else. Maybe try to
>> make daemon the owner of /usr/bin/lpr, just to see what happens

>>

>>     Didier

>>
>> _______________________________________________
>
> Did that. It didn't help. I even did the lpr command as root. Might
> root be excluded from printing for some reason? Might it try
> writing to the directory as the user that invoked the lpr command
> instead of as the suid'd user? Might I have to add
> users, one by one, to group lp?
>
> I added blank lines for readability:
>
> root@notlookedfor:/home/hendrik# ls -l /usr/bin/lpr
> -rwsr-sr-x 1 root lp 26536 Nov 20 2014 /usr/bin/lpr
>
> root@notlookedfor:/home/hendrik# chown daemon /usr/bin/lpr
>
> root@notlookedfor:/home/hendrik# ls -l /usr/bin/lpr
> -rwxr-xr-x 1 daemon lp 26536 Nov 20 2014 /usr/bin/lpr
>
> root@notlookedfor:/home/hendrik# /usr/bin/lpr -h -PHL3170CDW Documents/math/Librationism=1407.3877v3.ps
> lpr: cannot open /var/spool/lpd/hl3170cdw/.seq: Permission denied

JFTR^2: I'm using lprng with a Brother printer and my lpr is

-rwxr-xr-x 2 root root 361728 Jun 11 2012 /usr/bin/lpr

which works find (/var/spool/lpd permissions are identical) because lpr
really just talk to lpd (the 'line printer daemon') which runs as user
daemon and hence, can write to the spool directory.

Changing the owner of the lpr binary just means some 'user daemon' can
now overwrite the file aka 'open it for writing'. You could try running
the lpr command via strace -f which ought to provide more information
about the 'permission denied' error.