Bug 66475 - smb.conf param expansion: quotes are lost
smb.conf param expansion: quotes are lost
Status: CLOSED CURRENTRELEASE
Product: Red Hat Raw Hide
Classification: Retired
Component: samba (Show other bugs)
1.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jay Fenlason
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-06-10 21:47 EDT by kenneth_porter
Modified: 2014-08-31 19:24 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-05-17 15:35:50 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 kenneth_porter 2002-06-10 21:47:39 EDT
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 11:00:19 EDT
Seems to happen in 2.2.5, too.
Comment 2 Jay Fenlason 2003-02-13 12:11:20 EST
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.