Ralf Stubner [EMAIL PROTECTED] wrote:
On Sun, Oct 01, 2006 at 21:13 +0200, Frank Küster wrote:
I didn't check the mktexnam code - but I'm a little surprised here. I
wasn't aware of the test for SYSTEXMF, but in case the test fails,
i.e. the input is from a private TEXMF tree, shouldn't the
On Mon, Oct 02, 2006 at 08:07 +0200, Frank Küster wrote:
Okay, you are right, indeed this check is already done. So we could
gain some additional security by making sure that the SYSTEXMF variable
is not set in the user environment, but only read from the system-wide
texmf.cnf.
That's
Steve Langasek [EMAIL PROTECTED] wrote:
The old solution was a security problem because the directories were
world-writable -- /var/mail is not, the directory is only writable by the
'mail' group -- which almost certainly makes symlink attacks possible,
looking at the source of mktexmf, as
[please note the different bug number]
Steve Langasek [EMAIL PROTECTED] wrote:
Where does the input for the cache come from? If the input is always from a
privileged location (i.e., /usr/share, /usr/lib, /etc), then it's possible
-- and, I think, vastly preferable -- to have an suid wrapper
On Sun, Oct 01, 2006 at 14:48 +0200, Frank Küster wrote:
Steve Langasek [EMAIL PROTECTED] wrote:
Where does the input for the cache come from? If the input is always from a
privileged location (i.e., /usr/share, /usr/lib, /etc), then it's possible
-- and, I think, vastly preferable -- to
Ralf Stubner [EMAIL PROTECTED] wrote:
On Sun, Oct 01, 2006 at 14:48 +0200, Frank Küster wrote:
The input can come from the current directory, the user's own TEXMF tree
or any directory specified in the MFINPUTS (etc.) variable.
The output goes to the user's own TEXMF tree, though. If the
On Sun, Oct 01, 2006 at 21:13 +0200, Frank Küster wrote:
I didn't check the mktexnam code - but I'm a little surprised here. I
wasn't aware of the test for SYSTEXMF, but in case the test fails,
i.e. the input is from a private TEXMF tree, shouldn't the output go to
TEXMFVAR
Thiemo Seufer [EMAIL PROTECTED] wrote:
No, or I do not understand what you mean.
I meant the the earlier security bug you mentioned. To me, the solution
for the earlier bug as well as the current one looks like keeping the
font cache in /var but maintaining it via a mktexmf user.
That would
8 matches
Mail list logo
