Bug 66475 - smb.conf param expansion: quotes are lost
Summary: smb.conf param expansion: quotes are lost
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: samba   
(Show other bugs)
Version: 1.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jay Fenlason
QA Contact: David Lawrence
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-06-11 01:47 UTC by kenneth_porter
Modified: 2014-08-31 23:24 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-05-17 19:35:50 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description kenneth_porter 2002-06-11 01:47:39 UTC
Using samba-2.2.4-3 from Red Hat Rawhide.

I had the following string in my smb.conf:

   print 
command = /usr/bin/lpr -r "-P%p" "%s"

Running at a high debug level, I see this as a result of a 
print attempt:

[2002/06/05 14:40:45, 3] 
printing/print_generic.c:print_run_command(88)
  Running the command `/usr/bin/lpr -r "-
PLexmark" 
"smbprn.000070.vRIntd' gave 2

As you can see, the trailing quote is getting 
lost before the command is 
run.

I then checked the loading of the config file and I see that 
the quote is  
still there when the config file is parsed:

  doing parameter print command = 
/usr/bin/lpr -r "-P%p" "%s"

So far I haven't found where the quote is getting 
lost.

Removing the quotes from %s allows the command to run. I had initially 
quoted it 
thinking the client's filename was used there, but it now 
appears that it's a "safe" temp name 
that doesn't need quotes.

Comment 1 Trond Eivind Glomsrxd 2002-07-12 15:00:19 UTC
Seems to happen in 2.2.5, too.

Comment 2 Jay Fenlason 2003-02-13 17:11:20 UTC
It appears the actual bug is in the parsing of all string config values.  I can
easily replicate the problem with the Comment field of any share.  It only
occurs if the string ends in a " character, so an easy workaround is to use the
' character (if possible--shells treat "" strings different from '' ones).

If this isn't fixed in 2.2.8-pre1, I'm going to pass it upstream.


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