Re: libtool /tmp security

[Akim Demaille]

| On Mar 13, 2000, "Gary V. Vaughan" <[EMAIL PROTECTED]> wrote:
| > I would still like to see {auto{conf,make},libtool} use Ralf
| > Engelschall's shtool (or a variant of it) to encapsulate the
| > portability issues of things like mkdir -p and mkdir -m 700 into a
| > single script rather than scattered across the sources...

Absolutely.  Missing and alike should be moved from Automake to
Autoconf actually, and the ability that Automake and Libtool plug new
modules is fundamental too.

As for mkdir -m, it seems to me that

(umask 700 && mkdir /tmp/foo)

is just fine.

| Yup.  Something like this has been suggested for automake's
| `missing', and I'm thinking about the best way to make it work.
| 
| I've just tought we could keep it in an initial section of
| `configure'.  Then, we'd arrange for `autoconf' to preserve that
| section, and we'd need some tool to add/remove/update shtools within
| that special section of configure.  Comments?

This idea has been raised several times, and it is big work.  We have
to choose a solution, and spread it in the *tools.  Now, it seems to
me that yet we are totally unable to target a release, which I sorely
regret.  Adding that new pressure to Autoconf 2.15 is not something
I'm willing to do.

Let's close Automake 1.5, Autoconf 2.15 and Libtool 1.4 some day,
which means, let's avoid big changes.  We have to converge some day.
I'm dying for the day Automake will use Autoconf's new feature, and
since it is apparently not the next release, super-missing and other
shtools should be delayed till then.

Akim

Re: libtool /tmp security

[Earnie Boyd]

--- Akim Demaille <[EMAIL PROTECTED]> wrote:
-8<-
> 
> As for mkdir -m, it seems to me that
> 
> (umask 700 && mkdir /tmp/foo)
> 
> is just fine.
> 
-8<-

Why use /tmp at all?  Since autoconf is for portibility you can't really assume
that /tmp exists.  Why not simply create a temporary directory in the current
working directory?  IMO this would handle any security issues as well as any
race issues.

Earnie.

__
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

Re: libtool /tmp security

[Akim Demaille]

> "Earnie" == Earnie Boyd <[EMAIL PROTECTED]> writes:

Earnie> --- Akim Demaille <[EMAIL PROTECTED]> wrote: -8<-
>>  As for mkdir -m, it seems to me that
>> 
>> (umask 700 && mkdir /tmp/foo)

Grmph, 077.

>> 
>> is just fine.
>> 
Earnie> -8<-

Earnie> Why use /tmp at all?  Since autoconf is for portibility you
Earnie> can't really assume that /tmp exists.  Why not simply create a
Earnie> temporary directory in the current working directory?  IMO
Earnie> this would handle any security issues as well as any race
Earnie> issues.

Let it be for speed issues, I'm in favor of /tmp via TMPDIR.  This
should be portable enough, and testing it beforehand is OK.

Now, if experts consider this is a security hole...

Re: libtool /tmp security

[Earnie Boyd]

--- Akim Demaille <[EMAIL PROTECTED]> wrote:
> > "Earnie" == Earnie Boyd <[EMAIL PROTECTED]> writes:
> 
> Earnie> --- Akim Demaille <[EMAIL PROTECTED]> wrote: -8<-
> >>  As for mkdir -m, it seems to me that
> >> 
> >> (umask 700 && mkdir /tmp/foo)
> 
> Grmph, 077.
> 
> >> 
> >> is just fine.
> >> 
> Earnie> -8<-
> 
> Earnie> Why use /tmp at all?  Since autoconf is for portibility you
> Earnie> can't really assume that /tmp exists.  Why not simply create a
> Earnie> temporary directory in the current working directory?  IMO
> Earnie> this would handle any security issues as well as any race
> Earnie> issues.
> 
> Let it be for speed issues, I'm in favor of /tmp via TMPDIR.  This
> should be portable enough, and testing it beforehand is OK.
> 
> Now, if experts consider this is a security hole...

You missed the point; /tmp isn't portable, it doesn't always exist (E.G.: MSDOS
or WINDOWS).  At least with TMPDIR I can set it to be whatever I want it to be.
 If you want speed do mkdir ./foo instead of mkdir -m /tmp/foo.


=
---
   Earnie Boyd: 
__Cygwin: POSIX on Windows__
Cygwin Newbies: 
   __Minimalist GNU for Windows__
  Mingw32 List: 
Mingw Home: 

__
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

Re: libtool /tmp security

[Alexandre Oliva]

On Mar 15, 2000, Earnie Boyd <[EMAIL PROTECTED]> wrote:

> Why use /tmp at all?

Because those commands are run at install time, when the
program/library has to be relinked for installation.  In this case, we
can't assume the current directory, i.e., the build tree, is writable.

> Since autoconf is for portibility you can't really assume that /tmp
> exists.

If /tmp doesn't exist, pretty much everything breaks, unless TMPDIR is
set.  And it does use $TMPDIR, so we're fine.

-- 
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org}   Write to mailing lists, not to me

Re: libtool /tmp security

[Akim Demaille]

> "Earnie" == Earnie Boyd <[EMAIL PROTECTED]> writes:

>> Let it be for speed issues, I'm in favor of /tmp via TMPDIR.  This

Earnie> You missed the point; /tmp isn't portable, it doesn't always
Earnie> exist (E.G.: MSDOS or WINDOWS).  At least with TMPDIR I can
Earnie> set it to be whatever I want it to be.

That's precisely what I meant, and Alexandre also demonstrated it is
required for Libtool.

Earnie> If you want speed do mkdir ./foo instead of mkdir -m /tmp/foo.

Nope, I'm talking about possibly mounted src dirs, while /tmp is
local, so faster.

Akim

Re: libtool /tmp security

[Earnie Boyd]

--- Akim Demaille <[EMAIL PROTECTED]> wrote:
> > "Earnie" == Earnie Boyd <[EMAIL PROTECTED]> writes:
> 
> >> Let it be for speed issues, I'm in favor of /tmp via TMPDIR.  This
> 
> Earnie> You missed the point; /tmp isn't portable, it doesn't always
> Earnie> exist (E.G.: MSDOS or WINDOWS).  At least with TMPDIR I can
> Earnie> set it to be whatever I want it to be.
> 
> That's precisely what I meant, and Alexandre also demonstrated it is
> required for Libtool.
> 

Ah, thanks.

> Earnie> If you want speed do mkdir ./foo instead of mkdir -m /tmp/foo.
> 
> Nope, I'm talking about possibly mounted src dirs, while /tmp is
> local, so faster.
> 

Ok, I understand.  But you need to default to ./ if both /tmp and TMPDIR are
non-existant.
 

=
---
   Earnie Boyd: 
__Cygwin: POSIX on Windows__
Cygwin Newbies: 
   __Minimalist GNU for Windows__
  Mingw32 List: 
Mingw Home: 

__
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

Why does Makefile depend on BUILT_SOURCES?

[OKUJI Yoshinori]

  I'm now investigating why the latest CVS version of Automake doesn't
work with GRUB nicely. I've already sent some patches to bug-automake,
but I encountered another problem; "make distclean" doesn't work.

  After looking into it by "make -d distclean", this turned out:

1. The target `distclean' updates the target `Makefile'.
2. The target `Makefile' depends on $(BUILT_SOURCES).
3. $(BUILT_SOURCES) is "stage2_size.h" in our case and it depends on
   "pre_stage2" which is a data file.
4. "pre_stage2" depends on "pre_stage2.exec" which is an executable.
5. Overall, "make distclean" tries to build the executable, but it
   never succeed, because every source files for "pre_stage2.exec"
   includes the header file "config.h" under the top directory, which
   has already been removed when the target "distclean" was executed
   under the top directory.

  The solution may be to get rid of the dependency in the item 2, so
my question is why Makefile must depend on BUILT_SOURCES. Is there
some good reason?

Thanks,
Okuji

Re: Why does Makefile depend on BUILT_SOURCES?

[Tom Tromey]

> ">" == OKUJI Yoshinori <[EMAIL PROTECTED]> writes:

>> 2. The target `Makefile' depends on $(BUILT_SOURCES).

>>   The solution may be to get rid of the dependency in the item 2,
>> so my question is why Makefile must depend on BUILT_SOURCES. Is
>> there some good reason?

Only a historical one.  In the old days we computed dependencies
early, so we had to make sure that built sources were built before the
dependency-generation step.  Now I think we don't need this.  I'm in
favor of removing this.

Send a patch...  maybe Jim will apply it :-)

Tom

Re: libtool /tmp security

[Gary V. Vaughan]

On Wed, Mar 15, 2000 at 03:16:16AM -0300, Alexandre Oliva wrote:
> On Mar 13, 2000, "Gary V. Vaughan" <[EMAIL PROTECTED]> wrote:
> 
> > I would still like to see {auto{conf,make},libtool} use Ralf
> > Engelschall's shtool (or a variant of it) to encapsulate the
> > portability issues of things like mkdir -p and mkdir -m 700 into a
> > single script rather than scattered across the sources...
> 
> Yup.  Something like this has been suggested for automake's
> `missing', and I'm thinking about the best way to make it work.

That was me! =)O|  Actually Tom said several people recommended that
approach to him independently.

> I've just tought we could keep it in an initial section of
> `configure'.  Then, we'd arrange for `autoconf' to preserve that
> section, and we'd need some tool to add/remove/update shtools within
> that special section of configure.  Comments?

The shtool distribution comes with code to combine tools into a single
script, so we could probably use that as a basis.

I was wondering when in the package lifecycle the appropriate scripts
should be chosen and tacked into configure?  Might autoconf perhaps
start to ship a comprehensive set which it installs into the package
source tree at autoconf time, and then running configure could tack
only the shtool's needed on the build host on to the front of
config.status?  I'll bet Akim would love to write a macro to do all
this =)O| =)O|

That might be overkill (I guess it depeds on how many shtool's we are
likely to end up with), and perhaps tacking them all onto the front of
configure at autoconf time would be plenty good enough for half a
dozen or so.

Either way, adding them to the front of an existing script is
priceless.  There are already too many shell droppings in
autoconfiscated packages!

Cheers,
Gary.
-- 
  ___  _   ___   __  _ mailto:[EMAIL PROTECTED]
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___   [EMAIL PROTECTED] 
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \  
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page:  /___/  /___/  gpg public key:
http://www.oranda.demon.co.uk   http://www.oranda.demon.co.uk/key.asc