Date: Mon, 19 Jun 2000 08:40:30 +1000 From: Peter Jeremy <peter.jeremy@ALCATEL.COM.AU> To: current@FreeBSD.ORG Subject: Re: mktemp() patch Message-ID: <00Jun19.084031est.115299@border.alcanet.com.au> In-Reply-To: <Pine.BSF.4.21.0006071758550.11848-100000@freefall.freebsd.org>; from kris@FreeBSD.ORG on Thu, Jun 08, 2000 at 11:11:42AM %2B1000
next in thread | previous in thread | raw e-mail | index | archive | help
As one of the proponents of the change, my apologies for not taking part in this thread earlier - I am way behind in my reading of most of the lists. On Thu, Jun 08, 2000 at 11:11:42AM +1000, Kris Kennaway wrote: >Instead of using only alphabetic characters, the patch uses the following >character set: > >0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz@#%^-_=+:,.~ This was discussed in -audit as well - and most of the points brought up here have already been discussed there. > Peter, I hope I've got the right version of the patch Looks about right. The character set matches my last suggestion (the only other item was making base64 and padchar `const'). On Thu, Jun 08, 2000 at 04:08:18PM +1000, Matthew Dillon wrote: > It would be a good idea to avoid any punctuation. Could you please provide some rationale for this statement. I agree there are valid reasons for not using some specific characters, but I don't see any justification for a blanket ban. On Fri, Jun 09, 2000 at 04:15:45AM +1000, Garance A Drosihn wrote: >context that reads blah@blah:blah as userid@hostname:fname Good point. I hadn't considered the impact of letting [rs]cp loose on the output from mktemp. >At the same time, I do like to see the set expanded as much as >possible, without causing any problems. That was my rationale as well. I went through the 7-bit printable set and wiped out the characters I though would cause problems. On Thu, Jun 08, 2000 at 09:51:34PM +1000, Bruce Evans wrote: >Why are we still using the pid? It is highly non-random. It was >originally used to ensure a separate starting point for separate >processes, The other advantage is that it was easy to locate and delete temp files associated with dead processes. Given the change to a BASE64 PID, this is no longer true and I agree with Kris that it can be dropped. If you need to clean up after dead processes, you'll need to use lsof or fstat to work out what files are still wanted. On Fri, Jun 09, 2000 at 01:48:20PM +1000, Kris Kennaway wrote: >I'm not sure that weird filesystems are a valid argument against mktemp() >naming - there are LOTS of UNIX code which assumes UNIX namespace >conventions, and it's not just mktemp() which is going to break on weird >filesystems. For example, should we limit all FreeBSD file names to 8.3 >single-case in case someone wants to run from an old-style MSDOS >partition? I agree with Kris here. I briefly considered the problem of support for non-UFS filesystems and decided that it was reasonable for standard Unix utilities to make use of the facilities offered by the native filesystem - ie UFS. In any case, I believe that mktemp(3) will always return a valid filename for the filesystem (though it might take some time to pick one). _gettemp() [the function underlying mktemp(3), mkstemp(3) etc] invokes lstat(2) on each sample path and requires that lstat() returns ENOENT for it to succeed. If lstat() is given an invalid pathname, it should return something like EINVAL - which will make _gettemp() try again. If a filesystem implementation returns ENOENT when given a pathname that is not valid on that filesystem, then the filesystem implementation is broken and should be fixed. Note that AFAIK, currently FreeBSD cannot meet mkstemp guarantees on _any_ non-local filesystem (and some shared filesystem types) because the relevant locking mechanisms either don't exist or don't work. On Fri, Jun 09, 2000 at 02:57:02PM +1000, Garance A Drosihn wrote: >Should the new mktemp check some kind of environment variable, >and use a different list (or maybe even a totally different >algorithm) depending on the value? I think that selecting between a number of different algorithms based on an environment variable might be over-kill. However it could be useful to allow the user to control the character set used by mktemp() via an environment variable. For example MKTEMP_CHARSET="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz._-" would give you the POSIX portable filename character set (apart from the `no leading hyphen' bit). Maybe support two variables - one to defines the allowable initial characters and another to define the allowable following characters if it's different. The downside is that this means that the user can pretty much control the temporary filenames used by processes - which means it would need to be disabled for setuid (and maybe setgid) processes. On Fri, Jun 09, 2000 at 03:08:57PM +1000, Dan Nelson wrote: >I still suggest not using symbols at all, since I'd like to be able to >quickly remove tempfiles by hand without worrying if I have to escape # >or ^, etc. ... >I'd rather stick with easy-to-read and type tempnames. `easy-to-read and type' is basically incompatible with `hard-to-guess'. I'd suggest that most people will be deleting mktemp filenames using wildcards, shell-completion or cut-and-paste. Any shell that can't understand a filename that it has globbed is broken. Similarly, any shell that does shell completion without protecting the result from $IFS or globbing is broken. And if in doubt, you can always paste between single quotes. >mktemp() doesn't use TMPDIR; the user gets to pass a template of his >choosing, which could reasonably be just "bobXXXXX.tmp". To pick a nit: mktemp() doesn't allow suffixes, you need to use mkstemps(). On Sat, Jun 10, 2000 at 04:05:34PM +1000, Bruce Evans wrote: >There is the POSIX.1 portable filename character set: [A-Za-z._-] (from >which the hyphen shall not be used as the first character of a portable >filename). I suspect that whilst POSIX guarantees that those characters can be used in filenames, it does not guarantee that the names will refer to distinct files. Case-insensitive filesystems are fairly common - which would reduce the effective set to [a-z._-] - which is ridiculous. On Sun, Jun 11, 2000 at 02:41:12AM +1000, Daniel C. Sobral wrote: >Mind you, shells don't have problems with any character at all in a >filename if they are properly written, but if you are expecting the >filenames generated by mktemp() to be handled by shell, they ought to >pass the > >IFS=':'; for file in $filelist > >test. Why? Isn't it equally valid to state that they ought to pass IFS='a'; for file in $filelist or setting IFS to any other random character? On Mon, Jun 12, 2000 at 07:51:15AM +1000, David Scheidt wrote: > "@" is used as the line >erase character in some shells. "#" is rubout in some shells. Generally very old shells that were designed on the assumption that the user was sitting at a KSR33 or similar. Does anyone using FreeBSD have any stty cchars set to printable characters? Do any FreeBSD shells (including ports) default to using printable cchars? I would be very surprised if the answer to either question was yes. (Anyone who has erase=@ is either an expert at escaping it, or we aren't going to hear from them because they won't be able to type the mailing list address :-). On Mon, Jun 12, 2000 at 08:39:44AM +1000, Peter Wemm wrote: ># is a comment # shouldn't be treated as a comment in the output from command substitution or in variable expansions. There may be a problem with evals. >~ at the beginning is a ~username Only at the beginning of a word and the proposed mktemp can't generate ~ at the beginning of a word. >^ is an alias for | in old shells Yes, but not in any shells used on FreeBSD. These points were all discussed in -audit. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?00Jun19.084031est.115299>