Bug 66475

Summary:	smb.conf param expansion: quotes are lost
Product:	[Retired] Red Hat Raw Hide	Reporter:	kenneth_porter
Component:	samba	Assignee:	Jay Fenlason <fenlason>
Status:	CLOSED CURRENTRELEASE	QA Contact:	David Lawrence <dkl>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	1.0	CC:	jfeeney
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
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:	---	Target Upstream Version:
Embargoed:

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.