[tex-live] Status of restricted \write18 and epstopdf conversion

[Manuel Pégourié-Gonnard]

Hi all,

As some of you already noticed, and Norbert explained in reply, two days
ago we temporarily removed nearly all programs, including epstopdf, from
the list of allowed programs in restricted \write18, since the don't
impose enough restrictions (if any) on the output file name, hence
making openout_any=p ineffective.

In the meanwhile, we prepared and tested internally a newer, restricted
version of esptopdf, called repstopdf, and added it again to the list of
allowed program. We also made a trivial change to the epstopdf package
so that it now calls repstopdf. It means automagic esptopdf conversion
is back again, and hopefully this time without security issues.

The only programs currently allowed are kpsewhich and fc-match, which
are obviously safe, and repstopdf, which has been specially crafted for
this purpose: all options are checked to avoid injection, so the only
external program called is ghostscript with -dSAFER, and the output file
name is subject to conditions more restrictive than openout_any=p (it
was easier than to implement a true support of this variable). For more
details, please look in texmf.cnf and epstopdf.pl itself.

This is most probably the definitive list of programs for this release.
Later, we wish to include more programs, but will check the security
aspect of each individual program before (implementing restricted
version, possibly as wrappers, when necessary). Our primary goal was to
have the eps inclusion work, and it does.

Tlnet and the images have been rebuilt today to include these changes.
The newer version, dated from today, should soon be at your usual mirror.

Testing is even more welcome than ever.

Manuel.

[Alexander Cherepanov]

Hi Manuel!

Post by Manuel Pégourié-Gonnard
repstopdf, which has been specially crafted for
this purpose: all options are checked to avoid injection, so the only
external program called is ghostscript with -dSAFER,

First of all, you talk about
rsync://tug.org/tldevsrc/Master/texmf-dist/scripts/epstopdf/epstopdf.pl
(size: 17776, last changed: 2009/10/15 03:39:50), right?

As far as I can see, there are no checks for injections in --outfile=
at all. Arbitrary command execution is possible:

./repstopdf --outfile='out.pdf" - -c quit; echo Hi! > out; true "' input.eps

This should be prohibited, I suppose?

The following should be prohibited as well:

./repstopdf --gscmd="gs
" input.eps

./repstopdf --autorotate="None
" input.eps

Post by Manuel Pégourié-Gonnard
and the output file
name is subject to conditions more restrictive than openout_any=p (it
was easier than to implement a true support of this variable).

There is a couple of quirks on Windows. Relative paths on other
drives (like "c:dir/file") are allowed. And alternate data streams
on NTFS (like "file:ads") are allowed (didn't test it but should work;
no big deal in a any case but to be on a safe side it's better to ban
it). Both could be ruled out by checking for a colon.

And you can use backslash as a path separator on cygwin:

./repstopdf --outfile='dir\..\..\..\out.pdf' input.eps

(tested on cygwin1.5 only).

Approximate patch:

--- epstopdf.pl.orig 2009-10-15 03:39:50.000000000 +0400
+++ epstopdf.pl 2009-10-18 02:50:24.000000000 +0400
@@ -277,7 +277,7 @@
# \label{val_autorotate}
die "Invalid value for autorotate: '$::opt_autorotate' (use 'All', 'None' or 'PageByPage').\n"
if ($::opt_autorotate and
- not $::opt_autorotate =~ /^(None|All|PageByPage)$/);
+ not $::opt_autorotate =~ /^(None|All|PageByPage)\z/);

### option BoundingBox types
my $BBName = "%%BoundingBox:";
@@ -320,10 +320,20 @@
my ($drive, $path, $basename) = splitpath($OutputFilename);
$ok = 0 if $basename =~ /^\./;
}
+ # disallow colon on Windows. It could be used either after a drive
+ # (like "a:dir\file") or for an alternate data stream (like
+ # "file:ads").
+ if ($^O eq "MSWin32" || $^O eq "cygwin") {
+ $ok = 0 if $OutputFilename =~ /:/;
+ }
+ # disallow quote
+ $ok = 0 if $OutputFilename =~ /"/;
+ # disallow newline (just to be on a safe side)
+ $ok = 0 if $OutputFilename =~ /\n/;
# disallow absolute path
$ok = 0 if file_name_is_absolute($OutputFilename);
# disallow going to parent directory
- my $ds = ($^O eq "MSWin32") ? qr([\\/]) : qr(/);
+ my $ds = ($^O eq "MSWin32" || $^O eq "cygwin") ? qr([\\/]) : qr(/);
$ok = 0 if $OutputFilename =~ /^\.\.$ds|$ds\.\.$ds/;
# we passed all tests
die error "Output filename '$OutputFilename' not allowed in restricted mode." unless $ok;
@@ -335,8 +345,8 @@
$GS = $::opt_gscmd;
# validate GS \label{val_gscmd}
if ($restricted) {
- $GS =~ /^(gs|mgs|gswin32c|gs386|gsos2)$/
- or $GS =~ /^gs[\-_]?(\d|\d[\.-_]?\d\d)c?$/
+ $GS =~ /^(gs|mgs|gswin32c|gs386|gsos2)\z/
+ or $GS =~ /^gs[\-_]?(\d|\d[\.-_]?\d\d)c?\z/
or die error "Value of gscmd '$GS' not allowed in restricted mode.";
}
}

It should be tested more thoroughly (at least at cygwin1.7) but I want
to get it out earlier.

Alexander Cherepanov

[Manuel Pégourié-Gonnard]

Post by Alexander Cherepanov
First of all, you talk about
rsync://tug.org/tldevsrc/Master/texmf-dist/scripts/epstopdf/epstopdf.pl
(size: 17776, last changed: 2009/10/15 03:39:50), right?

Right.

Post by Alexander Cherepanov
As far as I can see, there are no checks for injections in --outfile=
at all.

You are perfectly right. Thanks a lot for noticing. I was so
concentrated on the openout_any checks for this one that I forgot the
injection problem.

Post by Alexander Cherepanov
./repstopdf --outfile='out.pdf" - -c quit; echo Hi! > out; true "' input.eps
This should be prohibited, I suppose?

Of course.

Post by Alexander Cherepanov
./repstopdf --gscmd="gs
" input.eps
./repstopdf --autorotate="None
" input.eps

Right. I should now my perl regexes better.

Post by Alexander Cherepanov
There is a couple of quirks on Windows. Relative paths on other
drives (like "c:dir/file") are allowed. And alternate data streams
on NTFS (like "file:ads") are allowed (didn't test it but should work;
no big deal in a any case but to be on a safe side it's better to ban
it). Both could be ruled out by checking for a colon.

Right.

Post by Alexander Cherepanov
./repstopdf --outfile='dir\..\..\..\out.pdf' input.eps
(tested on cygwin1.5 only).

Ok. Cygwin is quite complicated to get right, being sort of a mix of
Unix and Windows. Thanks again for this information.
It looks like a good start at first glance. I'll review it more
thoroughly tomorrow (too tired now) and apply it.

Post by Alexander Cherepanov
+ # disallow quote
+ $ok = 0 if $OutputFilename =~ /"/;
+ # disallow newline (just to be on a safe side)
+ $ok = 0 if $OutputFilename =~ /\n/;

This is not enough to prevent injection.

repstopdf --debug --outfile="$(echo hi >~/pwned; echo foo.pdf)" foo.eps

still gives arbitrary command execution. This one can be circumvented,
at least on Unix, by quoting the outfile name with single quotes (and
then disallow single quote in the value, or better escape them (since a
legitimate user might want to use single quotes in his file names).

But I'm thinking it would probably be better to use the list form of
system() so that we avoid to call a shell at all, to really prevent
injection.

Manuel.

[Manuel Pégourié-Gonnard]

Post by Manuel Pégourié-Gonnard

Post by Alexander Cherepanov
There is a couple of quirks on Windows. Relative paths on other
drives (like "c:dir/file") are allowed.

By the way, I'm surprised. According to my tests, those were catched by
the file_name_is_absolute() test. Anyway, I agree that we should forbid
':' for the sake of alternate data streams, so it doesn't matter.

Post by Manuel Pégourié-Gonnard
But I'm thinking it would probably be better to use the list form of
system() so that we avoid to call a shell at all, to really prevent
injection.

After a night's thinking, I didn't change my mind. Trying to trap every
possibly abusable shell special character is nearly impossible,
especially on windows, were quoting is so weird. In the latest version:

http://tug.org/svn/texlive/trunk/Master/texmf-dist/scripts/epstopdf/epstopdf.pl

I applied your patch and changed the way we call GS in order to avoid
calling a shell (or a cmd.exe). This way, command-line injection is
definitely not possible.

The bad side is, this form of pipe open doesn't work on windows [1] so I
decided to use a temporary file here. According to my tests and
File::Temp's documentation, the temporary file is correctly removed when
the script finishes.

Since this is quite an important implementation change, testing
(especially on windows/cygwin) is very welcome.

Manuel.

[1] There is a workaround documented in perlfork. Unfortunately it
doesn't work with the Perl version we ship. It works however with Perl
5.10.0 from strawberry Perl, according to my tests.

[Alexander Cherepanov]

Hi Manuel!

Post by Manuel Pégourié-Gonnard

Post by Manuel Pégourié-Gonnard

Post by Alexander Cherepanov
There is a couple of quirks on Windows. Relative paths on other
drives (like "c:dir/file") are allowed.

By the way, I'm surprised. According to my tests, those were catched by
the file_name_is_absolute() test.

That's strange. The following perl script:

use File::Spec::Functions qw(file_name_is_absolute);
print file_name_is_absolute("c:dir/file") ? "absolute" : "relative";

gives "relative" for me on linux, windows (bundled tlperl), and
cygwin. And this is right as this path is not absolute:-) IMHO this
path is neither relative but there is no file_name_is_relative
function to check for this.

Post by Manuel Pégourié-Gonnard
Anyway, I agree that we should forbid
':' for the sake of alternate data streams, so it doesn't matter.

Post by Manuel Pégourié-Gonnard
But I'm thinking it would probably be better to use the list form of
system() so that we avoid to call a shell at all, to really prevent
injection.

After a night's thinking, I didn't change my mind. Trying to trap every
possibly abusable shell special character is nearly impossible,
http://tug.org/svn/texlive/trunk/Master/texmf-dist/scripts/epstopdf/epstopdf.pl
I applied your patch and changed the way we call GS in order to avoid
calling a shell (or a cmd.exe). This way, command-line injection is
definitely not possible.

Cool.

Post by Manuel Pégourié-Gonnard
The bad side is, this form of pipe open doesn't work on windows [1] so I
decided to use a temporary file here.

Nice.

Post by Manuel Pégourié-Gonnard
According to my tests and
File::Temp's documentation, the temporary file is correctly removed when
the script finishes.

Seems so.

Post by Manuel Pégourié-Gonnard
Since this is quite an important implementation change, testing
(especially on windows/cygwin) is very welcome.

Basic tests works fine for me on linux, windows, and cygwin1.5.
cygwin1.5 work with temporary file and with pipe. So you can leave
temporary file only for bare windows if you want.

Alexander Cherepanov

[Alexander Cherepanov]

Hi Manuel!

Post by Manuel Pégourié-Gonnard

Post by Alexander Cherepanov
./repstopdf --outfile='dir\..\..\..\out.pdf' input.eps
(tested on cygwin1.5 only).

Ok. Cygwin is quite complicated to get right, being sort of a mix of

Definitely.

Post by Manuel Pégourié-Gonnard
Unix and Windows. Thanks again for this information.
It looks like a good start at first glance. I'll review it more
thoroughly tomorrow (too tired now) and apply it.

Post by Alexander Cherepanov
+ # disallow quote
+ $ok = 0 if $OutputFilename =~ /"/;
+ # disallow newline (just to be on a safe side)
+ $ok = 0 if $OutputFilename =~ /\n/;

This is not enough to prevent injection.
repstopdf --debug --outfile="$(echo hi >~/pwned; echo foo.pdf)" foo.eps

(probably you mean single quotes here, so command substitution happens
when calling gs, not when calling repstopdf)

Post by Manuel Pégourié-Gonnard
still gives arbitrary command execution. This one can be circumvented,
at least on Unix, by quoting the outfile name with single quotes (and
then disallow single quote in the value, or better escape them (since a
legitimate user might want to use single quotes in his file names).

I've also thought about all this quoting but only after sending the
email out:-( That requires some work...
Other issue here is environment variables like %TEMP% on Windows.

Post by Manuel Pégourié-Gonnard
But I'm thinking it would probably be better to use the list form of
system() so that we avoid to call a shell at all, to really prevent
injection.

This is also not that easy but you seem to manage it (just received
your next mail), nice. Will look into the new version now.

Alexander Cherepanov

[Manuel Pégourié-Gonnard]

Hi Alexander,

Post by Alexander Cherepanov

Post by Manuel Pégourié-Gonnard
repstopdf --debug --outfile="$(echo hi >~/pwned; echo foo.pdf)" foo.eps

(probably you mean single quotes here, so command substitution happens
when calling gs, not when calling repstopdf)

Yep. Actually, I was thinking of

\write18{repstopdf --debug --outfile="$(echo hi >\string~/pwned; echo
foo.pdf)" foo.eps}

Post by Alexander Cherepanov
I've also thought about all this quoting but only after sending the
email out:-( That requires some work...
Other issue here is environment variables like %TEMP% on Windows.

Yep. That's why I don't want to try catching every single shell and
cmd.exe feature: I'm sure I'd forget something.

Post by Alexander Cherepanov
This is also not that easy but you seem to manage it (just received
your next mail), nice. Will look into the new version now.

It is actually very easy on Unix, the only problem being with windows.
I'm looking forward to hearing your comments on the new version.

Manuel.

[Alexander Cherepanov]

Hi Manuel!

Post by Manuel Pégourié-Gonnard

Post by Alexander Cherepanov
This is also not that easy but you seem to manage it (just received
your next mail), nice. Will look into the new version now.

It is actually very easy on Unix, the only problem being with windows.
I'm looking forward to hearing your comments on the new version.

All mentioned problems are solved. So, do you consider it a security
bug (shell injection in epstopdf and/or directory traverse in
repstopdf)? CVE, advisory and the like? Are there any distros which
have restricted shell-execute with allowed epstopdf? miktex2.8, what
else?

I also didn't waste time today, here is the next part of the problems;)

1. In repstopdf, you protect dot-files on unix from overwriting but
don't protect files in dot-directories, say .ssh/authorized_keys when
run from ~ .

Is it checked in tex when openout_any=r or openout_any=p?

2. repstopdf --nogs " ../file" (and ">../file") bypasses checks but
you have already fixed it:-)

3. repstopdf implements openout_any=p but ignores openin_any. Having
shell_escape=p (partially) and openin_any=p (paranoid) in texmf.cnf at
the same time doesn't seem very eccentric.

4. In epstopdf.pl, the extension is removed from the name of input
file by the following line:

$OutputFilename =~ s/\.[^\.]*$//;

It should not span directory parts like in
./other/sub/dir/file_wo_extension .

The remaining items are only for the case of Windows.

5. In tex, special symbols in \write18 are not handled properly, so

repstopdf input.eps & echo Pwned
repstopdf input.eps | echo Pwned

works fine;-) Seems \write18 should be switched off entirely on
Windows (short of fixing tex binaries).

6. When you have gswin32c.exe in current directory (could be written
from tex) repstopdf calls it so any defense is defeated. Maybe there
is a perl module to walk through %path% ...

7. The same for tex with repstopdf.bat AFAIR (don't have win at hand
right now).

Alexander Cherepanov

[Akira Kakuto]

Alexander Cherepanov wrote:
... ...

Post by Alexander Cherepanov
The remaining items are only for the case of Windows.
5. In tex, special symbols in \write18 are not handled properly, so
repstopdf input.eps & echo Pwned
repstopdf input.eps | echo Pwned
works fine;-) Seems \write18 should be switched off entirely on
Windows (short of fixing tex binaries).

Did you test those? In restricted mode,
\write18{repstopdf input.eps & echo Pwned}
and
\write18{repstopdf input.eps | echo Pwned}
fail on Windows.
(!!! Error: Unknown option or too many input files)

Thanks,
Akira

[Alexander Cherepanov]

Hi Akira!

Post by Akira Kakuto

Post by Alexander Cherepanov
The remaining items are only for the case of Windows.
5. In tex, special symbols in \write18 are not handled properly, so
repstopdf input.eps & echo Pwned
repstopdf input.eps | echo Pwned
works fine;-) Seems \write18 should be switched off entirely on
Windows (short of fixing tex binaries).

Did you test those?

Sure. Just made a clear test on WinXP Home Edition SP3 Rus with
texlive2009 net-installed yesterday (scheme-basic + epstopdf).

1. In an empty dir created write18-pipe.tex:

\immediate\write18{repstopdf input.eps | echo Pwned 1}
\immediate\write18{repstopdf input.eps & echo Pwned 2}
\immediate\write18{repstopdf input.eps && echo Pwned 3}
\csname @@end\endcsname\end

and go.bat:

set PATH=C:\texlive\2009\bin\win32
path
latex write18-pipe.tex
pause

2. Click go.bat from Explorer.

3. Results. write18-pipe.log:

This is pdfTeX, Version 3.1415926-1.40.10 (Web2C 2009) (format=latex 2009.10.18) 19 OCT 2009 12:42
entering extended mode
restricted \write18 enabled.
%&-line parsing enabled.
**write18-pipe.tex
(./write18-pipe.tex
LaTeX2e <2009/09/24>
Babel <v3.8l> and hyphenation patterns for english, usenglishmax, dumylang, noh
yphenation, loaded.
runsystem(repstopdf input.eps | echo Pwned 1)...executed (allowed).

runsystem(repstopdf input.eps & echo Pwned 2)...executed (allowed).

runsystem(repstopdf input.eps && echo Pwned 3)...executed (allowed).

)
Here is how much of TeX's memory you used:
5 strings out of 495062
143 string characters out of 3182549
45108 words of memory out of 3000000
3282 multiletter control sequences out of 15000+200000
3640 words of font info for 14 fonts, out of 3000000 for 9000
28 hyphenation exceptions out of 8191
5i,0n,1p,74b,8s stack positions out of 5000i,500n,10000p,200000b,50000s

No pages of output.

On the screen:

C:\test>set PATH=C:\texlive\2009\bin\win32

C:\test>path
PATH=C:\texlive\2009\bin\win32

C:\test>latex write18-pipe.tex
This is pdfTeX, Version 3.1415926-1.40.10 (Web2C 2009)
restricted \write18 enabled.
entering extended mode
(./write18-pipe.tex
LaTeX2e <2009/09/24>
Babel <v3.8l> and hyphenation patterns for english, usenglishmax, dumylang, noh
yphenation, loaded.
Pwned 1
epstopdf ($Id: epstopdf.pl 15569 2009-09-30 00:21:49Z karl $) 2.11
!!! Error: Cannot open "input.eps": No such file or directory
epstopdf ($Id: epstopdf.pl 15569 2009-09-30 00:21:49Z karl $) 2.11
!!! Error: Cannot open "input.eps": No such file or directory
Pwned 2
epstopdf ($Id: epstopdf.pl 15569 2009-09-30 00:21:49Z karl $) 2.11
Usage: epstopdf [OPTION]... [EPSFILE]

[Skip epstopdf usage.]

!!! Error: Unknown option or too many input files
)
No pages of output.
Transcript written on write18-pipe.log.

C:\test>pause
[Message in Russian.]

Don't know why the the third line doesn't work but the first two ones
work. Setting

set PATH=C:\texlive\2009\bin\win32;%PATH%

instead of

set PATH=C:\texlive\2009\bin\win32

doesn't change anything.

Is some other info needed?

Alexander Cherepanov

[Akira Kakuto]

Post by Alexander Cherepanov
runsystem(repstopdf input.eps | echo Pwned 1)...executed (allowed).
runsystem(repstopdf input.eps & echo Pwned 2)...executed (allowed).
runsystem(repstopdf input.eps && echo Pwned 3)...executed (allowed).

These messages are somewhat annoying, but the true meaning is
"invoked the command". They do not mean "succeeded".
Actually the invoked commands have failed in the restricted mode.

The same message will be written also on Unix for a failed
command:
\write18{repstopdf input.eps ; rm -fr /}

Thanks,
Akira

[Alexander Cherepanov]

Hi Akira!

Post by Akira Kakuto

Post by Alexander Cherepanov
runsystem(repstopdf input.eps | echo Pwned 1)...executed (allowed).
runsystem(repstopdf input.eps & echo Pwned 2)...executed (allowed).
runsystem(repstopdf input.eps && echo Pwned 3)...executed (allowed).

These messages are somewhat annoying, but the true meaning is
"invoked the command". They do not mean "succeeded".
Actually the invoked commands have failed in the restricted mode.

Please take a look at the screen output -- it shows "Pwned" twice.

Alexander Cherepanov

[Akira Kakuto]

Post by Alexander Cherepanov
Please take a look at the screen output -- it shows "Pwned" twice.

Very strange!
I cannot reproduce your result.
Here all three lines are
!!! Error: Unknown option or too many input files
without printing "Pwned".

I'll investigate the problem.

Thanks,
Akira

[Akira Kakuto]

Post by Akira Kakuto

Post by Alexander Cherepanov
Please take a look at the screen output -- it shows "Pwned" twice.

Very strange!
I cannot reproduce your result.
Here all three lines are
!!! Error: Unknown option or too many input files
without printing "Pwned".
I'll investigate the problem.

I've found the reason.
I'm not using texlua as a wrapper of repstopdf etc., while TeX Live
uses texlua. texlua can set shellenabledp independently of
texmf.cnf. I have found that luatex
set shell escape enabled in texlua mode. The source is

if (lua_only)
shellenabledp = true;

in luainit.c.
Therefore in all commands called by TeX Live wrappers,
shell escape is fully allowed!!

Best,
Akira

[Taco Hoekwater]

Hi,

Post by Akira Kakuto
I've found the reason.
I'm not using texlua as a wrapper of repstopdf etc., while TeX Live
uses texlua. texlua can set shellenabledp independently of
texmf.cnf.

I have not followed this discussion closely, but are you
sure this is related to the luatex internals? To me it
looks more like a side-effect of \write18: I suspect that
the operating system is starting a command shell to execute
the generated command line, and that that shell interprets
the special symbols it finds.

Post by Akira Kakuto
I have found that luatex
set shell escape enabled in texlua mode. The source is
if (lua_only)
shellenabledp = true;
in luainit.c.

I really had to do that. texlua is first and foremost a
lua interpreter. Because of the restricted shell feature,
texlua now has to listen to the texmf.cnf settings even
in embedded lua code inside luatex tex input. And because
the actual code is shared between luatex and texlua, if I
did not explicitly enable shellenabledp in the texlua case,
the lua interpreter would not have a working os.execute()
c.s. at all.

Best wishes,
Taco

[Alexander Cherepanov]

Hi Taco!

Post by Taco Hoekwater

Post by Akira Kakuto
I've found the reason.
I'm not using texlua as a wrapper of repstopdf etc., while TeX Live
uses texlua. texlua can set shellenabledp independently of
texmf.cnf.

I have not followed this discussion closely, but are you
sure this is related to the luatex internals? To me it
looks more like a side-effect of \write18: I suspect that
the operating system is starting a command shell to execute
the generated command line, and that that shell interprets
the special symbols it finds.

AIUI \write18 doesn't start a shell but calls repstopdf which in turn
runs "perl epstopdf.pl" through a number of wrappers. And one of these
wrappers indeed runs next command with all arguments in a shell. At
this point a pipe symbol from arguments seems to touch a shell.

Alexander Cherepanov

[Akira Kakuto]

Post by Taco Hoekwater
I have not followed this discussion closely, but are you
sure this is related to the luatex internals? To me it
looks more like a side-effect of \write18: I suspect that
the operating system is starting a command shell to execute
the generated command line, and that that shell interprets
the special symbols it finds.

My previous mail may be wrong. Two different processes may
not be able to share the value of shellenabledp.

The internal command in the restricted mode is, for example

repstopdf input.eps ^| echo Pwned 1

The special meaning of | is changed to be a simple
file name by ^|. Here it is really treated not to be
a pipe symbol and the above command fails.

Thanks,
Akira

[Alexander Cherepanov]

Hi Akira!

Post by Akira Kakuto

Post by Akira Kakuto

Post by Alexander Cherepanov
Please take a look at the screen output -- it shows "Pwned" twice.

Very strange!
I cannot reproduce your result.
Here all three lines are
!!! Error: Unknown option or too many input files
without printing "Pwned".
I'll investigate the problem.

I've found the reason.

Good.

Post by Akira Kakuto
I'm not using texlua as a wrapper of repstopdf etc., while TeX Live

BTW why wrappers around .bat files are needed in texlive?

Post by Akira Kakuto
uses texlua. texlua can set shellenabledp independently of
texmf.cnf. I have found that luatex
set shell escape enabled in texlua mode. The source is
if (lua_only)
shellenabledp = true;
in luainit.c.
Therefore in all commands called by TeX Live wrappers,
shell escape is fully allowed!!

Well, I will leave it for others to assess.

Alexander Cherepanov

[T T]

Post by Alexander Cherepanov

Post by Akira Kakuto
I'm not using texlua as a wrapper of repstopdf etc., while TeX Live

BTW why wrappers around .bat files are needed in texlive?

It is actually the other way around, we have some .bat wrappers around
texlua scripts but not for (r)epstopdf (see my other message).

Post by Alexander Cherepanov
AIUI \write18 doesn't start a shell but calls repstopdf which in turn
runs "perl epstopdf.pl" through a number of wrappers. And one of these
wrappers indeed runs next command with all arguments in a shell. At
this point a pipe symbol from arguments seems to touch a shell.

That is true and the problem is .bat wrappers that we use. Wherever a
.bat wrapper is used it has to be executed through cmd.exe and then we
have a problem if the argument list contains special characters
interpreted by the shell like the command separator.

I don't see any other solution than to get rid of the .bat wrappers in
favour of .exe stubs, at least in the security sensitive contexts.
This will not happen before the release, unfortunately. It will take
some time get those security issues sorted.

Cheers,

Tomek

[T T]

Post by Akira Kakuto

Post by Akira Kakuto

Post by Alexander Cherepanov
Please take a look at the screen output -- it shows "Pwned" twice.

Very strange!
I cannot reproduce your result.
Here all three lines are
!!! Error: Unknown option or too many input files
without printing "Pwned".
I'll investigate the problem.

I've found the reason.
I'm not using texlua as a wrapper of repstopdf etc., while TeX Live
uses texlua. ?texlua can set shellenabledp independently of
texmf.cnf. I have found that luatex
set shell escape enabled in texlua mode. The source is
? ?if (lua_only)
? ? ? ?shellenabledp = true;
in luainit.c.
Therefore in all commands called by TeX Live wrappers,
shell escape is fully allowed!!

AFAIK, there are no texlua wrappers involved in calling (r)epstopdf
script. We used to have a generic texlua wrapper for calling scripts,
but not any more.

Cheers,

Tomek

[Manuel Pégourié-Gonnard]

Post by Alexander Cherepanov
All mentioned problems are solved. So, do you consider it a security
bug (shell injection in epstopdf and/or directory traverse in
repstopdf)? CVE, advisory and the like? Are there any distros which
have restricted shell-execute with allowed epstopdf? miktex2.8, what
else?

Currently no distro uses this restricted write18, except TL09 which is
still in testing phase. MikTeX makes everything differently: different
TeX implementation, different esptopf executable...

(That doesn't mean it's not worth checking if MikTeX is subject to some
of the problems we discussed here, but a priori their problems are not
the same as ours.)

Post by Alexander Cherepanov
I also didn't waste time today, here is the next part of the problems;)

Thanks ! -- but sigh, too :-)

Post by Alexander Cherepanov
1. In repstopdf, you protect dot-files on unix from overwriting but
don't protect files in dot-directories, say .ssh/authorized_keys when
run from ~ .
Is it checked in tex when openout_any=r or openout_any=p?

No. I did the same as TeX here, on purpose. I realised it may be a
problem with TeX, and interestingly enough I choose the same example as
you when writing to Karl :-) By the way, this particular example doesn't
work with TeX, since it will write .ssh/authorized_keys.tex (I tried).
But other fils in dot-directories could be dangerous. (My example is
~/.vim/plugin/badhack.vim since vim can launch arbitrary commands, but
there are probably plenty others.)

By the way, some configuration files are not in dot-dirs. Eg,
windowmaker puts its config in ~/GNUstep by default, and needless to say
there a lot of potential for arbitrary commands there. Moreover, some
people (including me) hold most of their configuration in ~/etc in order
to manage it more easily with a version control system.

So my conclusion is that openout_any=r is only a heuristic, and the only
real protection is to use openout_any=p and never compile (untrusted)
tex fils in your home, but in a "safe" subdirectory.

But anyway, since 'r' is sort of half of the heuristic, it would still
be good to implement the complete heuristic at some point (both in tex
and repstopdf).

Post by Alexander Cherepanov
2. repstopdf --nogs " ../file" (and ">../file") bypasses checks but
you have already fixed it:-)

That's what I like with the list form of system(): it fixes things you
didn't even think about. :-)

Post by Alexander Cherepanov
3. repstopdf implements openout_any=p but ignores openin_any. Having
shell_escape=p (partially) and openin_any=p (paranoid) in texmf.cnf at
the same time doesn't seem very eccentric.

Right. I'm going to implement real support for openXX_any this evening
(must do real-life work now): most of the job is already done.
(Obviously we can't hard-code 'p' for openin since it is too restrictive
and is not the default.)

Post by Alexander Cherepanov
4. In epstopdf.pl, the extension is removed from the name of input
$OutputFilename =~ s/\.[^\.]*$//;
It should not span directory parts like in
./other/sub/dir/file_wo_extension .

Unless I'm mistaken, this is indeed a bug, but not a security flaw. The
checks for about the file name are done after this line is executed, so
it will not result in a "forbidden" file being written to, only "the
wrong" file.
Right?

I'll look into the windows stuff later.

Thanks a lot for all your remarks,
Manuel.

[Alexander Cherepanov]

Hi Manuel!

Post by Manuel Pégourié-Gonnard

Post by Alexander Cherepanov
All mentioned problems are solved. So, do you consider it a security
bug (shell injection in epstopdf and/or directory traverse in
repstopdf)? CVE, advisory and the like? Are there any distros which
have restricted shell-execute with allowed epstopdf? miktex2.8, what
else?

Currently no distro uses this restricted write18,

I hope so.

Post by Manuel Pégourié-Gonnard
except TL09 which is still in testing phase.

Well, every beta-tester knows that the tested program could burn
his/her computer:-) Ok, no problem here.

Post by Manuel Pégourié-Gonnard
MikTeX makes everything differently: different
TeX implementation, different esptopf executable...

I'll get to this later.

Post by Manuel Pégourié-Gonnard

Post by Alexander Cherepanov
1. In repstopdf, you protect dot-files on unix from overwriting but
don't protect files in dot-directories, say .ssh/authorized_keys when
run from ~ .
Is it checked in tex when openout_any=r or openout_any=p?

No. I did the same as TeX here, on purpose. I realised it may be a
problem with TeX, and interestingly enough I choose the same example as
you when writing to Karl :-)

:-)

Post by Manuel Pégourié-Gonnard
By the way, this particular example doesn't
work with TeX, since it will write .ssh/authorized_keys.tex (I tried).

And here repstopdf starts to differ from tex.

BTW it's easy to bypass this restriction under windows: just add a
dot at the end of file name -- it's ignored by os but makes tex think
that there is already an extension.

Post by Manuel Pégourié-Gonnard
But other fils in dot-directories could be dangerous. (My example is
~/.vim/plugin/badhack.vim since vim can launch arbitrary commands, but
there are probably plenty others.)

Right.

Post by Manuel Pégourié-Gonnard
By the way, some configuration files are not in dot-dirs. Eg,
windowmaker puts its config in ~/GNUstep by default, and needless to say
there a lot of potential for arbitrary commands there. Moreover, some
people (including me) hold most of their configuration in ~/etc in order
to manage it more easily with a version control system.
So my conclusion is that openout_any=r is only a heuristic, and the only
real protection is to use openout_any=p and never compile (untrusted)
tex fils in your home, but in a "safe" subdirectory.

Then openout_any=r seems strange. It gives false sense of security.
The problem is not that it doesn't work, but rather that it makes you
think that it works while not really protecting.

Post by Manuel Pégourié-Gonnard
But anyway, since 'r' is sort of half of the heuristic, it would still
be good to implement the complete heuristic at some point (both in tex
and repstopdf).

If you cannot process untrusted .tex files in ~/ is there any sense in
keeping 'r' at all?

Post by Manuel Pégourié-Gonnard

Post by Alexander Cherepanov
2. repstopdf --nogs " ../file" (and ">../file") bypasses checks but
you have already fixed it:-)

That's what I like with the list form of system(): it fixes things you
didn't even think about. :-)

It's a similar but distinct issue -- note --nogs. It was fixed by
changing

open(OUT,">$OutputFilename")

to

open($OUT, '>', $OutputFilename)

Post by Manuel Pégourié-Gonnard

Post by Alexander Cherepanov
3. repstopdf implements openout_any=p but ignores openin_any. Having
shell_escape=p (partially) and openin_any=p (paranoid) in texmf.cnf at
the same time doesn't seem very eccentric.

Right. I'm going to implement real support for openXX_any this evening
(must do real-life work now): most of the job is already done.

Cool.

Post by Manuel Pégourié-Gonnard
(Obviously we can't hard-code 'p' for openin since it is too restrictive
and is not the default.)

Post by Alexander Cherepanov
4. In epstopdf.pl, the extension is removed from the name of input
$OutputFilename =~ s/\.[^\.]*$//;
It should not span directory parts like in
./other/sub/dir/file_wo_extension .

Unless I'm mistaken, this is indeed a bug, but not a security flaw. The
checks for about the file name are done after this line is executed, so
it will not result in a "forbidden" file being written to, only "the
wrong" file.
Right?

Yes, sorry, I should have mentioned it.

Post by Manuel Pégourié-Gonnard
I'll look into the windows stuff later.

Alexander Cherepanov

[Manuel Pégourié-Gonnard]

Post by Alexander Cherepanov

Post by Manuel Pégourié-Gonnard
By the way, this particular example doesn't
work with TeX, since it will write .ssh/authorized_keys.tex (I tried).

And here repstopdf starts to differ from tex.

Sure.

Post by Alexander Cherepanov
BTW it's easy to bypass this restriction under windows: just add a
dot at the end of file name -- it's ignored by os but makes tex think
that there is already an extension.

I don't think it is intended to be a restriction anyway.

Post by Alexander Cherepanov
Then openout_any=r seems strange. It gives false sense of security.
The problem is not that it doesn't work, but rather that it makes you
think that it works while not really protecting.

Perhaps it should be better documented...

Post by Alexander Cherepanov

Post by Manuel Pégourié-Gonnard

Post by Alexander Cherepanov
2. repstopdf --nogs " ../file" (and ">../file") bypasses checks but
you have already fixed it:-)

That's what I like with the list form of system(): it fixes things you
didn't even think about. :-)

It's a similar but distinct issue -- note --nogs. It was fixed by
changing
open(OUT,">$OutputFilename")
to
open($OUT, '>', $OutputFilename)

Oh, right, I didn't read your example carefully enough. I made this
change routinely, I had no example of abuse in mind. Thanks for
providing one :-)

Post by Alexander Cherepanov

Post by Manuel Pégourié-Gonnard
Right. I'm going to implement real support for openXX_any this evening
(must do real-life work now): most of the job is already done.

Cool.

Well, finally not. Looks like we are not shipping with restricted
\write18 enabled by default (nor easy to enable) after all (I just
discovered a quoting problem in the C part of the code on Unix, which
can be solved only by patching then recompiling everything).

Anyway, thanks a lot for all your help!

Manuel.

[Reinhard Kotucha]

Post by Manuel Pégourié-Gonnard
Currently no distro uses this restricted write18, except TL09 which
different TeX implementation, different esptopf executable...
(That doesn't mean it's not worth checking if MikTeX is subject to
some of the problems we discussed here, but a priori their problems
are not the same as ours.)

No need to worry about MikTeX. Christian is a good programmer but I
have the impression that he is not interested in any discussions. I'm
sure that he notices what's going on in TeX Live and adapts MikTeX
accordingly, if necessary.

Regards,
Reinhard

[Alexander Cherepanov]

Hi Manuel!

Post by Manuel Pégourié-Gonnard
By the way, this particular example doesn't
work with TeX, since it will write .ssh/authorized_keys.tex (I tried).

Try this:

\catcode0 12
\immediate\openout1 .ssh/authorized_keys^^@
\immediate\write1{PWNED}
\immediate\closeout1
\csname @@end\endcsname\end

Alexander Cherepanov

[Norbert Preining]

Honestly I see that going into a *stupid* direction.

bash is distributed and still you can do
echo > .ssh/authorized_keys

If you trust an arbitrary tex file you got that is like trusting
and arbitrary .sh file and running it, so it be.

We *cannot* expect to close all problematic usage cases where someone
can shoot himself, and *actually* I don't give a *s**** about it.

Best wishes

Norbert

-------------------------------------------------------------------------------
Dr. Norbert Preining Associate Professor
JAIST Japan Advanced Institute of Science and Technology preining at jaist.ac.jp
Vienna University of Technology preining at logic.at
Debian Developer (Debian TeX Task Force) preining at debian.org
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
TOOTING BEC (n.)
A car behind which one draws up at the traffic lights and hoots at
when the lights go green before realising that the car is parked and
there is no one inside.
--- Douglas Adams, The Meaning of Liff

[Alexander Cherepanov]

Hi Norbert!

Post by Norbert Preining
Honestly I see that going into a *stupid* direction.
bash is distributed and still you can do
echo > .ssh/authorized_keys
If you trust an arbitrary tex file you got that is like trusting
and arbitrary .sh file and running it, so it be.
We *cannot* expect to close all problematic usage cases where someone
can shoot himself, and *actually* I don't give a *s**** about it.

Sure, no problem, just write in big letters that processing untrusted
tex files is as dangerous as running untrusted shell scripts. All
these openout_any and -shell-restricted create the impression that
it's safe.

Alexander Cherepanov

[Philipp Stephani]

Post by Norbert Preining
Honestly I see that going into a *stupid* direction.
bash is distributed and still you can do
echo > .ssh/authorized_keys
If you trust an arbitrary tex file you got that is like trusting
and arbitrary .sh file and running it, so it be.

I think there was a time when TeX files were regarded as documents,
not as executable programs. Do you really want to see TeX macro
viruses like those in Word 95? Maybe the compilation of files in the
home directory and the opening of dotfiles should be disabled when
openout_any=p.

[Norbert Preining]

I think there was a time when TeX files were regarded as documents, not
as executable programs. Do you really want to see TeX macro viruses like
those in Word 95? Maybe the compilation of files in the home directory
and the opening of dotfiles should be disabled when openout_any=p.

Strange enough nobody complained in the last n years (not sure about the n)
where this feature was present, too ;-)

All that only came out (and that is good so) with the automatic epstopdf
conversion. But leaving that aside (we have reverted that already), all
other "features" have been present since years, and nobody complained,
nor did we get any reports of that "virus".

So I wouldn't overestimate the problem.

Best wishes

Norbert

-------------------------------------------------------------------------------
Dr. Norbert Preining Associate Professor
JAIST Japan Advanced Institute of Science and Technology preining at jaist.ac.jp
Vienna University of Technology preining at logic.at
Debian Developer (Debian TeX Task Force) preining at debian.org
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
GLASGOW (n.)
The feeling of infinite sadness engendered when walking through a
place filled with happy people fifteen years younger than yourself.
--- Douglas Adams, The Meaning of Liff

[Will Robertson]

Post by Norbert Preining
So I wouldn't overestimate the problem.

Hear, hear.

-- Will

[Victor Ivrii]

Post by Will Robertson

Post by Norbert Preining
So I wouldn't overestimate the problem.

Hear, hear.

Sure, all dangers of \write18 not only existed for years but many
people were aware of them. However the low grade morons who would like
to exploit these dangers were not among those who knew. But this
discussion of dangers may reach them (so ostrich policy is not as
stupid as some may think). Anyway a little diligence for alien TeX
sources (\write18 or playing with kitty-codes :-) to mask write18
would require a bit more caution) and we are safe!

Victor

Post by Will Robertson
-- Will

[Manuel Pégourié-Gonnard]

Post by Victor Ivrii
Sure, all dangers of \write18 not only existed for years but many
people were aware of them.

Please, can we try not to mix up everything? We are not discussing only
the dangers of \write18. The last example was about TeX's \openout
feature. Most of the previous discussion was about the new "restricted"
\write18 feature, whose dangers cannot be known for years, since it is
so new (and now withdrawn).

There is security implications with tex, and some of them are not
obvious and should be considered seriously. We should discuss and try to
solve the non-obvious things, and stating that some other obvious facts
have been known for years doesn't help.

Post by Victor Ivrii
However the low grade morons who would like
to exploit these dangers were not among those who knew. But this
discussion of dangers may reach them (so ostrich policy is not as
stupid as some may think). Anyway a little diligence for alien TeX
sources (\write18 or playing with kitty-codes :-) to mask write18
would require a bit more caution) and we are safe!

I don't want to start a lengthy discussion about security principles,
here is not the place, and all the points I would make can already be
found in many places on the net. Just let me say that I strongly
disagree with the "security" conceptions above.

Manuel.

[Manuel Pégourié-Gonnard]

Hi,

Post by Norbert Preining
Honestly I see that going into a *stupid* direction.
bash is distributed and still you can do
echo > .ssh/authorized_keys
If you trust an arbitrary tex file you got that is like trusting
and arbitrary .sh file and running it, so it be.

I'm sorry but I disagree. Comparing tex with sh is completely
inappropriate. TeX is supposed to be a document processor, and its
documentation strongly suggest it can *not* be used to execute arbitrary
commands. (That's the whole point of \write18 being disable by default
for all these years and our efforts for developing a restricted version
this year, and you know that.)

While I understand it's depressive/annoying/whatever for us developers
that so many problems/questions are raised at this time when we are
trying to get a release sorted, we should try to avoid excessive
reactions (like comparing tex to sh) and continue to examine the
questions in a rational way.

Concerning this precise question, I already said I don't think we need
to change it quickly (if ever), for the following reasons:

1. It is the documented behaviour, ie nobody ever pretended that tex
cannot overwrite "dangerous" files.

2. Some such critical files are not dot-files nor in dot-dirs anyway
(think ~/bin). We cannot guess every possible path to critical files,
and there's probably no point in trying. The only real protection is to
process untrusted tex documents in their own directory.

(Later, it may be good to forbid dot-dirs too just for the sake of
consistency, but maybe even better to just document that the only real
protection is to process untrusted document in a directory under which
no critical file lies.)

Manuel.

[Philip TAYLOR]

Post by Manuel Pégourié-Gonnard
I'm sorry but I disagree. Comparing tex with sh is completely
inappropriate. TeX is supposed to be a document processor, and its
documentation strongly suggest it can *not* be used to execute arbitrary
commands. (That's the whole point of \write18 being disable by default
for all these years and our efforts for developing a restricted version
this year, and you know that.

[snip]

I support Manual's point of view, and -- to my mind -- there
would be considerable benefit in actually calling the "sh"
variant of TeX something other than TeX. TeX should never
(IMHO) communicate with the O/S through the medium of \write
18; if communication with the O/S through \write 18 is
required, then a separate program should be invoked, which
we might call (for example) uberTeX. No users would ever
then inadvertently process a Trojan-laden document, since
the use of uberTeX would have to be a conscious decision
by that user.

** Phil.

[Manuel Pégourié-Gonnard]

Post by Philip TAYLOR
I support Manual's point of view, and -- to my mind -- there
would be considerable benefit in actually calling the "sh"
variant of TeX something other than TeX. TeX should never
(IMHO) communicate with the O/S through the medium of \write
18; if communication with the O/S through \write 18 is
required, then a separate program should be invoked, which
we might call (for example) uberTeX. No users would ever
then inadvertently process a Trojan-laden document, since
the use of uberTeX would have to be a conscious decision
by that user.

Note that is it sort of the current situation: uberTeX is called
'tex -shell-escape' :-)

Manuel.

[Philip TAYLOR]

Post by Manuel Pégourié-Gonnard
Note that is it sort of the current situation: uberTeX is called
'tex -shell-escape' :-)

OK, but is it not the case that, unless instructed otherwise,
the TeX Live installer can/will install that option and make
it the default, such that a user thereafter invoking just
"TeX" will in fact get "TeX -shell-escape" ? IMHO, this is
the most dangerous aspect : by all means require the user
to explicitly type "TeX -shell-escape" (or "uberTeX"), but
never never never set up the system such that the same effect
may thereafter be achieved simply by typing TeX ...

** Phil.

[Manuel Pégourié-Gonnard]

Post by Philip TAYLOR

Post by Manuel Pégourié-Gonnard
Note that is it sort of the current situation: uberTeX is called
'tex -shell-escape' :-)

OK, but is it not the case that, unless instructed otherwise,
the TeX Live installer can/will install that option and make
it the default, such that a user thereafter invoking just
"TeX" will in fact get "TeX -shell-escape" ?

No, it is not the case, and it never was the plan. The plan was that the
default enabled a *restricted* version of shell-escape, able to run only
a few carefully checked commands, in order to avoid tex begin equivalent
to 'tex -shell-escape'. We finally withdrawn that for TL09 since some
problems were found.

Post by Philip TAYLOR
IMHO, this is
the most dangerous aspect : by all means require the user
to explicitly type "TeX -shell-escape" (or "uberTeX"), but
never never never set up the system such that the same effect
may thereafter be achieved simply by typing TeX ...

Restricted shell-escape is not at all the same as the current
-shell-escape feature. I we think a bit about it, *tex is already
capable of running a few external commands (the mktex* scripts for all
of them, dvipdfmx for XeTeX). The point is to be able to control
precisely which commands can be run from a tex document.

Manuel.

Post by Philip TAYLOR
** Phil.

[Philip TAYLOR]

Post by Manuel Pégourié-Gonnard
No, it is not the case, and it never was the plan. The plan was that the
default enabled a *restricted* version of shell-escape, able to run only
a few carefully checked commands, in order to avoid tex begin equivalent
to 'tex -shell-escape'. We finally withdrawn that for TL09 since some
problems were found.
Restricted shell-escape is not at all the same as the current
-shell-escape feature. I we think a bit about it, *tex is already
capable of running a few external commands (the mktex* scripts for all
of them, dvipdfmx for XeTeX). The point is to be able to control
precisely which commands can be run from a tex document.

OK, I don't want to pursue this one excessively (mainly because,
it being a glorious autumn day, I am keen to get out cycling),
but isn't it /possible/ that through a clever combination of
dirty tricks, a Trojan could fake one of the very commands
that the restricted version of shell-escape is willing
to execute, thereby once again compromising the whole system ?

For myself, I strongly believe that /no/ version of shell-escape
should be installable as a default; if a user wants shell-escape,
then let him/her type it explicitly.

** Phil.

[Manuel Pégourié-Gonnard]

Post by Philip TAYLOR
OK, I don't want to pursue this one excessively (mainly because,
it being a glorious autumn day, I am keen to get out cycling),

I don't want to discuss this in details right now either, because this
feature has been temporarily withdrawn, and until TL09 is released, I
prefer concentrating on problems with TL09. We can discuss it later, of
course.

Post by Philip TAYLOR
but isn't it /possible/ that through a clever combination of
dirty tricks, a Trojan could fake one of the very commands
that the restricted version of shell-escape is willing
to execute, thereby once again compromising the whole system ?

One of the reasons that made us withdraw the feature for now is
precisely that this is not impossible now. When we re-introduce the
feature, we will try hard to make sure this (and other kinds of attacks)
is not possible. (Of course one can never be 100% sure, but the same is
true for many other features of *TeX and other software.)


Manuel.

[Michel Goossens]

rsync -vr --exclude=2008 --exclude=mactex* rsync://ftp.klid.dk/texlive-tlnet/ /home/goossens/save/texlive/2009
tar zxvf install-tl-unx.tar.gz
cd install-tl-20091026
./install-tl -repository /home/goossens/save/texlive/2009

This installs texlive correctly below /home/goossens/save/texlive/2009.

export PATH=/home/goossens/save/texlive/2009/bin/i386-linux:$PATH
tlmgr update --repository /home/goossens/save/texlive/2009 --list

tlmgr: package repository /mnt/data1/goossens/save/texlive/2009
The release version of the installation source and the installation media do not agree: source: , media: 2009
Please fix your location /mnt/data1/goossens/save/texlive/2009 at /home/goossens/save/texlive/2009/bin/i386-linux/tlmgr line 3929.

What am I doing wrong?

Note that I want to install texlive on several systems, and update them afterwards. Hence I prefer to have a local archive and then install from there, rather than run for each system from the internet.

Thanks for your help. Michel Goossens/CERN

[Norbert Preining]

Post by Michel Goossens

cd install-tl-20091026
./install-tl -repository /home/goossens/save/texlive/2009

This installs texlive correctly below /home/goossens/save/texlive/2009.

That is a BAD idea. You mixed
- installation SOURCE = repository = sync of tlnet = the place FROM where
files are installed (/home/goossens/save/texlive/2009)
and
- the place where you install TO, the installation place, TEXDIR, or whatever.

That *does* and will not work.

Please call install-tl as above, and use as DESTINATION, i.e., TEXDIR
int the path settings, something else but the same checkout.

Post by Michel Goossens
The release version of the installation source and the installation media do not agree: source: , media: 2009

Yes becasue by installing *OVER* the checkedout repository you destroyed
data that was present there.

Post by Michel Goossens
What am I doing wrong?

Mixing these two thing.

Imagine that the repository is somewhere on the net, the place where
Debian fetches its updated packages, sma ewith Ubuntu, smae with Suse,
same with Windows.

And Destination is the place of *your* installation.

Best wishes

Norbert

-------------------------------------------------------------------------------
Dr. Norbert Preining Associate Professor
JAIST Japan Advanced Institute of Science and Technology preining at jaist.ac.jp
Vienna University of Technology preining at logic.at
Debian Developer (Debian TeX Task Force) preining at debian.org
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
THURNBY (n.)
A rucked-up edge of carpet or linoleum which everyone says someone
will trip over and break a leg unless it gets fixed. After a year or
two someone trips over it and breaks a leg.
--- Douglas Adams, The Meaning of Liff