How about MODDIR being configure'able?

How about MODDIR being configure'able?

[Raúl Núñez de Arenas Coronado]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 920 bytes --]

    Hello all :))

    I'm new to this list an a-kinda-new for ZSH, and I would like to
follow and contribute to its development.

    I have a suggestion (I don't remember if I posted this a few
months ago, when I first used ZSH), for the next version 4.0.3:

    I would like to set up the MODDIR (directory where binary modules
of ZSH reside) through 'configure', and not by defining MODDIR prior
to compile and install using make.

    Defining the variable is quite error prone and I think that the
modules directory should be fully configurable.

    How about it?. I'm not familiar to autoconf, so I'm afraid I
cannot make the appropriate patches.

    Moreover, there is a call to mktemp that should be replaced with
a call to mkstemp in 'utils.c' for safety.

    BTW, is there any place where I can get the current development
version of ZSH for testing?

    That's all, an thanks a lot for ZSH :)

    Raúl

Re: How about MODDIR being configure'able?

[Bart Schaefer]

On Oct 15,  3:44pm, Raúl Núñez de Arenas Coronado wrote:
}
}     I would like to set up the MODDIR (directory where binary modules
} of ZSH reside) through 'configure', and not by defining MODDIR prior
} to compile and install using make.

MODDIR is $(libdir)/zsh/$(VERSION).  You can't change the zsh/$(VERSION)
part without breaking things, and nothing else is installed in $(libdir),
so the module path is as completely configurable as possible with

	configure --libdir=...

}     Moreover, there is a call to mktemp that should be replaced with
} a call to mkstemp in 'utils.c' for safety.

No, we've been over this before; there's even a comment in utils.c to
this effect:  zsh uses mktemp() in a safe way.  Specifically, the names
created by gettempname() are always opened with O_CREAT later, so if
they exist the open() call will fail.  Creating them with mkstemp(), on
the other hand, causes problems with redirections and NO_CLOBBER.

}     BTW, is there any place where I can get the current development
} version of ZSH for testing?

It's available at http://sourceforge.net/projects/zsh/.  Details can be
found in the file Etc/FAQ in the distribution you have; if it's not in
there, you've got a really old distribution.

(Hey, Peter, why isn't SourceForge mentioned in the META-FAQ document?)

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: How about MODDIR being configure'able?

[Clint Adams]

> No, we've been over this before; there's even a comment in utils.c to
> this effect:  zsh uses mktemp() in a safe way.  Specifically, the names
> created by gettempname() are always opened with O_CREAT later, so if
> they exist the open() call will fail.  Creating them with mkstemp(), on
> the other hand, causes problems with redirections and NO_CLOBBER.

Hmm.. shouldn't that be O_CREAT|O_EXCL, which we're not doing in
all cases?

Re: O_EXCL (was: How about MODDIR being configure'able?)

[Wayne Davison]

On Mon, 15 Oct 2001, Clint Adams wrote:
> Hmm.. shouldn't that be O_CREAT|O_EXCL, which we're not doing in
> all cases?

You are right that O_EXCL (when combined with O_CREAT) is the vital
part of the incantation when creating new temp files, but it is not an
error that some of our open() calls that include O_CREAT do not use
O_EXCL.  For instance, the calls that write out the history file need
to succeed even if the file already exists, but they also want to
succeed when the file doesn't exist.  This is not a security problem
since (sane) people put their history file into their home dir (or
another non-world-writable dir) which is not vulnerable to the "rogue
symlink" exploit.  The code that creates a file based on the return of
mktemp() is all using O_EXCL, so we're OK.

..wayne..

Re: O_EXCL (was: How about MODDIR being configure'able?)

[Clint Adams]

> symlink" exploit.  The code that creates a file based on the return of
> mktemp() is all using O_EXCL, so we're OK.

Not entirely, though I can't imagine anyone attempting
malicious acts upon someone's zftp session.

Index: Src/Modules/zftp.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Modules/zftp.c,v
retrieving revision 1.20
diff -u -r1.20 zftp.c
--- Src/Modules/zftp.c	2001/09/28 17:35:45	1.20
+++ Src/Modules/zftp.c	2001/10/16 04:06:41
@@ -1918,7 +1918,7 @@
      */
     if (zfstatfd == -1) {
 	fname = gettempname();
-	zfstatfd = open(fname, O_RDWR|O_CREAT, 0600);
+	zfstatfd = open(fname, O_RDWR|O_CREAT|O_EXCL, 0600);
 	DPUTS(zfstatfd == -1, "zfstatfd not created");
 #if defined(F_SETFD) && defined(FD_CLOEXEC)
 	/* If the shell execs a program, we don't want this fd left open. */

Re: How about MODDIR being configure'able?

[Peter Stephenson]

Bart Schaefer wrote:
> (Hey, Peter, why isn't SourceForge mentioned in the META-FAQ document?)

Index: Doc/Zsh/metafaq.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/metafaq.yo,v
retrieving revision 1.10
diff -u -r1.10 metafaq.yo
--- Doc/Zsh/metafaq.yo  2001/09/12 11:50:50     1.10
+++ Doc/Zsh/metafaq.yo  2001/10/16 09:53:44
@@ -92,6 +92,11 @@
 tt(http://foad.org/zsh/))
 )
 enditem()
+
+The up-to-date source code is available via anonymous CVS from Sourceforge.
+See url(http://sourceforge.net/projects/zsh/)\
+(http://sourceforge.net/projects/zsh/) for details.
+
 texinode(Mailing Lists)(The Zsh FAQ)(Availability)(Introduction)
 sect(Mailing Lists)
 cindex(mailing lists)

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************