FEATURE REQ: safe % expansion via new syntax

Luke Kenneth Casson Leighton lkcl at samba.org
Tue Feb 1 19:42:14 GMT 2000


if anyone's proposing changes to these, please bear in mind that i need to
have the functions and all uses of those functions work across process
boundaries (e.g smbd creates it; smbd and netlogond, spoolssd etc read
it).

this is why i proposed that all the %macro sobstitution variables be
stored in a tdb that is indexed by process id (pid) and by smb userid
(vuid), with INVALID_SMB_VUID as the default to use in the case where no
smb user has logged on yet (no SMBsesssetupX received, in other words, or
in security == share mode).

this _also_ solves the problem of what to do with TSE / WinDD etc all
other multi-user, single-smbd-process clients, because each multi-user
client will be allocated a different vuid, resulting in correct lookup of
%subst macro information.

at present, all single-smbd-process client-users will have the
sesssetup_user, and all _other_ user info (including unix groups) of the
FIRST SMBsesssetupX connected user to that process, which is simply and
plainly wrong.

this was fixed over two years ago in the actual file-handling code by
jeremy allison, but it didn't occur to anyone that the lp_xxx() parameters
would be a problem, including me.

luke

On Wed, 2 Feb 2000, Nicolas Williams wrote:

> 
> Proposal: There should be a way to specify that some substitutions
>           should be made in a way that is safe as far as Bourne Shell
> 	  command lines are concerned (e.g., if %f expands to a string
> 	  with special characters in it, it should be expanded to a
> 	  sutiably quoted string in 'print command' parameters).
> 
> Either all parameters that eventually result in a /bin/sh command line
> should expand special % tokens in this way or else there should be a way
> to specify, in smb.conf, that this quoting take place. One way to do the
> latter might be to have %"... work as %... would but in a safe way
> Bourne Shell-quoting wise.
> 
> The %"... feature would require changes to:
> 
>  - standard_sub()
>  - standard_sub_basic()
>  - string_sub()
>  - expand_env_var()
> 
> The * command feature would only require changes to functions that call
> smbrun().
> 
> I'm thinking of %s and %f which expand to file names in 'print command'
> parameters. I'm also thinking of the 'open command' and 'close command'
> parameters implemented by a patch by Andy Bakun which allow
> administrators to specify a command to be called when a file is opened
> or closed.
> 
> Since those commands are run via smbrun() and, eventually, via /bin/sh,
> any strings that may be passed in by users should be appropriately
> quoted. IMNSHO.
> 
> The open/close command patch would allow me to set up shares for the
> purpose of securely launching applications remotely without having to
> deal with the horror of the 'magic script' parameter.
> 
> The 'magic script' parameter should be deprecated, IMNSHO, and Andy
> Bakun's patch should be included, again, IMNSHO.
> 
> Security is not the only objective I have in mind: any file name should
> work even if it contains special characters in it, provided it's a valid
> name (most people would be surprised at what can be a valid file name!).
> 
> The relevant URLs are:
> 
> http://us1.samba.org/listproc/samba/March1999/0510.html
> 
> http://www.reac.com/samba/
> 
> Nico
> -DISCLAIMER: an automatically appended disclaimer may follow. By posting-
> -to a public e-mail mailing list I hereby grant permission to distribute-
> -and copy this message.-
> 
> This message contains confidential information and is intended only 
> for the individual named.  If you are not the named addressee you 
> should not disseminate, distribute or copy this e-mail.  Please 
> notify the sender immediately by e-mail if you have received this 
> e-mail by mistake and delete this e-mail from your system.
> 
> E-mail transmission cannot be guaranteed to be secure or error-free 
> as information could be intercepted, corrupted, lost, destroyed, 
> arrive late or incomplete, or contain viruses.  The sender therefore 
> does not accept liability for any errors or omissions in the contents 
> of this message which arise as a result of e-mail transmission.  If 
> verification is required please request a hard-copy version.  This 
> message is provided for informational purposes and should not be 
> construed as a solicitation or offer to buy or sell any securities or 
> related financial instruments.
> 

<a href="mailto:lkcl at samba.org"   > Luke Kenneth Casson Leighton    </a>
<a href="http://www.cb1.com/~lkcl"> Samba and Network Development   </a>
<a href="http://samba.org"        > Samba Web site                  </a>
<a href="http://www.iss.net"      > Internet Security Systems, Inc. </a>
<a href="http://mcp.com"          > Macmillan Technical Publishing  </a>

 ISBN1578701503 DCE/RPC over SMB: Samba and Windows NT Domain Internals



More information about the samba-technical mailing list