Bug 143038 - cups does not call smb backend with username/password
cups does not call smb backend with username/password
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: samba (Show other bugs)
rawhide
All Linux
medium Severity high
: ---
: ---
Assigned To: Jay Fenlason
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-15 16:40 EST by Matthew S. Hallacy
Modified: 2014-08-31 19:27 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-24 15:34:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matthew S. Hallacy 2004-12-15 16:40:22 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041111 Firefox/1.0

Description of problem:
This is the configuration from /etc/cups/printers.conf

<DefaultPrinter deskjet>
Info Deskjet
DeviceURI smb://username:password@WORKGROUP/wuzzy/deskjet
Location HP Deskjet 3650
State Idle
Accepting Yes
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
</Printer>

When directed to print, cups calls /usr/lib/cups/backend/smb with
smb://WORKGROUP/wuzzy/deskjet, which means it is explicitly removing
the username:password. Obviously this fails since we are not
authenticated with the SMB share we're trying to print to. Manually
calling /usr/lib/cups/backend/smb with the proper URI works, and my
own temporary fix was a bash script:

~# cat /usr/lib/cups/backend/smb
#! /bin/bash
/usr/lib/cups/backend/smb.real
smb://username:password@WORKGROUP/wuzzy/deskjet $2 $3 \"$4\" $5 \"$6\"

Obviously this is not portable, cups needs to be fixed to pass on the
username/password.

Version-Release number of selected component (if applicable):
cups-1.1.22-1

How reproducible:
Always

Steps to Reproduce:
1. Add printer to be accessed via SMB
2. Attempt to print
3. View resulting NT_ACCESS_DENIED error message.
    

Actual Results:  Repeated access denied errors.

Expected Results:  Printout
Comment 1 Tim Waugh 2004-12-20 07:11:46 EST
Confirmed with 1.1.22-6.
Comment 2 Tim Waugh 2004-12-30 09:03:05 EST
On closer inspection everything looks fine as far as cupsd is concerned: the
DEVICE_URI environment variable is correctly set in smbspool's environment,
complete with username and password.

Any problems beyond that belong to the samba package.
Comment 3 Jay Fenlason 2005-01-06 10:51:55 EST
This is a regression in cups.  The version in FC3 supplies smbspool with a 
correct printer URI in both argv[0] and DEVICE_URI.  The version in rawhide 
supplies a damaged URI in argv[0].  The smbspool man page says "smbspool tries 
to get the URI from argv[0].  If argv[0] contains the name of the program then 
it looks in the  DEVICE_URI environment variable.", so smbspool is working as 
documented. 
 
CUPS needs to either supply a correct URI in argv[0] or only supply one in 
DEVICE_URI.  Supplying a damaged URI in argv[0] is Just Wrong. 
Comment 4 Tim Waugh 2005-01-06 11:22:13 EST
DEVICE_URI is authoritative; argv[0] is informative.  See the CUPS Software
Programmers Manual, 3 "Writing Filters" [referenced by 5 "Writing Backends"]:

Command Line Arguments

[...]

printer - The name of the printer queue (normally this is the name of the
program being run)

[...]

Environment Variables

[...]

DEVICE_URI - The output device URI

[...]

Since smbspool intends to be compatible with the CUPS interface for backends, it
needs to make sure that it uses DEVICE_URI when set.
Comment 5 Jay Fenlason 2005-01-06 12:16:32 EST
In samba-3.0.8 and later smbspool prefers DEVICE_URI over argv[0] (current 
rawhide has 3.0.10-2, FC2 and FC3 and RHEL3 also ship post-3.0.8 versions of 
Samba).  However, the Samba documentation was not.  I've opened an upstream 
doc bug to get this corrected. 
 
What version of Samba are you running? 
Comment 6 Jay Fenlason 2005-10-24 15:34:55 EDT
Looks like this is fixed in rawhide. 

Note You need to log in before you can comment on or make changes to this bug.