[Pkg-cups-devel] Bug#501719: cups-pdf: doesn't play well with NetWare shares

[Luca Capello]

Hi Volker!

First of all, thank you for the inline quoting, I really appreciate.

On Sat, 18 Oct 2008 22:25:56 +0200, Volker Behr wrote:
> On Fri, 2008-10-17 at 21:55 +0200, Luca Capello wrote:
>> The more I think about it, the more I don't understand why CUPS-PDF
>> wants to set the ownership for the output directory :-(
>
> CUPS-PDF creates by default a new directory for each user that is only
> accessible by this user (since the created documents might be
> confidential and therefore must not be accessible by everyone by
> default).

I don't think it's the printer driver/software to determine which
printer's output (being on paper or digital format) should be
confidential and not widely accessible.  CUPS-PDF should act exactly
like a physical printer: it's the *user* that should preserve her/his
documents' confidentiality.

> To make it accessible by just one single user the directory is
> chown-ed to this user and the permissions are set to 700.

FWIW, I found out an more explicative pages about NetWare mounts [1]:

  Ownership
    All objects appear to be owned by the logged-in user. chown(2)
    returns EPERM.

  Permissions
    Unix permissions set by chmod(2) appear correctly to stat(2), but
    only execute permissions are honoured by the kernel. All other
    permission checking is handled by NetWare. Files with none of the
    "write" bits set get flagged as NetWare "read-only".

If I understood correctly, without checking the code, but only from the
errors I experienced, if the output directory already exists it's not
chown-ed, while it should be.

>> With my feelings above, this is still a bug in CUPS-PDF.
>
> I disagree that this is a bug - it behaves exactly as designed.

As I explained above, I don't share your design :-D

However, since I've now completely understood the problem and I could
find a solution, I won't investigate more on this.

> Nevertheless I admit that I should make a clearer statement in the
> documentation that I assume a filesystem for the output that features
> all basic properties of UNIX-filesystems.

I think we've three bugs here:

1) a documentation one about the features of the filesystem for the
   output directory (this is the original bug)

2) CUPS-PDF not catching all the Ghostscript errors [2]

3) CUPD-PDF not setting the ownership for the output directory when the
   latter already exists

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://www-uxsup.csx.cam.ac.uk/pwf-linux/ncpfs-quirks.html
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=yes&bug=501719#15
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 314 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-cups-devel/attachments/20081019/d1d565a7/attachment.pgp