[buildd-tools-devel] Bug#528963: Bug#528963: schroot: copyfile does not expand variables

[Detlef Vollmann]

Roger Leigh wrote:
> On Sat, May 16, 2009 at 08:08:47PM +0200, Detlef Vollmann wrote:
>> Package: schroot
>> Version: 1.2.2
>> Severity: wishlist
>>
>> Sometimes I want to copy user specific files.
>> Instead of hardcoding the username in the respective copyfiles list,
>> I'd like to use ${AUTH_USER}.
>> With the attached patch, this works.
> 
> Thanks for the patch.

> I'm not really sure if this is something we should be allowing.
I'm not sure what you mean here:
  a - use of 'AUTH_USER'
  b - use of variable expansion in COPYFILES

a: it's documented in schroot-setup(5)
b: well, it make things clearer.
My previous approach (on a version that didn't have COPYFILES)
used another setup file to copy these files.
But with COPYFILES all files to be copied seemed to be in one
list, so I added my files there as well -- but I needed
user specific paths.

> It exposes internal details of how the scripts work in the configuration
> files, which makes it hard to change them in the future once people
> start relying on them.
Hmmm, I think the interface (i.e. using normal shell variable expension
syntax) is a natural one, and yes, I'd expect that this would work
in the future as well (however it's implemented).

> Is the eval strictly necessary?
I don't know any other way to implement this in bash (or Posix shell).
I understand that 'eval' is some kind of security risk, as the setup
script is run as root.
So if the script-config file or the copyfiles file is writeable by
a non-root user then it opens a big security hole.
But if files in /etc/schroot are writeble by non-root users you
probably have a security hole anyway.

>  Likewise the use of backticks [$() is
> a better choice, by the way]?
I agree that $() is better than backticks.

>  Is there any other way of accomplishing
> the same thing in the script?
I worked on something similar for quite a while and couldn't
find another way to do it in a shell script.  But that doesn't
mean that there is no other way...

> Also, will this work for files with spaces in the name?
Not as in the patch, but this should work:
file="$(eval "echo $file")"

Best Regards,
   Detlef