Subject: Re: [ecasound] problems linking ecawave on FreeBSD
From: Kai Vehmanen (k_AT_eca.cx)
Date: Wed Oct 10 2001 - 02:29:49 EEST
On Mon, 24 Sep 2001, The Anarcat wrote:
>> I'm not sure why FreeBSD
>> installs Qt2.x as -lqt2, but on the other hand it's not the only platform
>> that does it... (some trouble with libtool?).
> I don't know, exactly. I guess I should talk to Qt maintainer.
Well, actually, there's one very good reason for installing with a
different base name: multi-version build-environment.
Having multiple incompatible versions installed is no problem for libtool
versioning (ie. you can have libecasound.so.7 for ecasound 2.0.x, and
libecasound.so.8 for 2.1devX/2.2.x), but only one can be selected for
compiling new apps (is libecasound.so a symbolic link to .so.7 or .so.8).
>> Hmm, how about something like "LIBS=-lqt2 ./configure" for the fbsd port?
> I will try that. But wouldn't ./configure make LIBS=-lqt -lqt2?
Possibly... depends on your shell. :)
>> This is best handled in ecawave's configure-script (just take the
>> thread-setup from ecasound's configure.in).
> Ok. I had some problems duplicating the code in there ($host is NONE for
> some reason), so the patch is simply:
Patch applied to ecawave (ecamegapedal already had this
thread-check).
>> This is probably caused by the new temporary directory creation code in
>> 'ecasound/kvutils/temporary_file_directory.h'.
[...]
>> What does "stat /tmp/ecawave-anarcat" look like?
[...]
> Well now I have another problem. The directory doesn't exist anymore.
> Isn't ecawave supposed to create it?
[...]
> What's worse, ecawave *deletes it*!!! This is really odd.
This is normal. If the directory is empty, it is removed when ecawave
exits.
> You mean stat as in:
[...]
> anarcat_AT_shall [ecawave]$ stat /tmp/ecawave-anarcat/
> File: "/tmp/ecawave-anarcat/"
> Size: 512 Allocated Blocks: 2 Filetype: Directory
> Mode: (0755/drwxr-xr-x) Uid: (1000/anarcat) Gid: (0/wheel)
> Device: 226308 Inode: 6598 Links: 2
> Access: Mon Sep 24 00:44:19 2001
> Modify: Mon Sep 24 00:44:19 2001
> Change: Mon Sep 24 00:44:19 2001
Ok, something goes wrong. The very idea of the tempdir handling is that
nobody else has access to the directory. It seems that your (or freebsd
default) /tmp dir has sticky-bits set (or something else) that override
the permissions as set by ecawave ('mkdir(tmpdirname, 0700)').
>> I suspect geteuid() or getegid()
>> functions work differently between fbsd and linux. You can test this by
>(kvutils) st_gid doesn't match.
Hmm, I'll remove at least this 'st_gid' check. It's true that it only
causes trouble.
> Are these checks really necessary?
Yep. Ecawave needs a secure way to handle temporary files. It can't use
the normal mkstemp()/etc functions, because it has no direct access to the
files - it only knows the filenames. So the only solution is to create a
secure directory, in which files can be created securely, even with
insecure file-creation methods.
Btw; you can override the tempdir location by rerefining the TMPDIR or
TMP variable for ecawave.able. This is probably the easiest fix.
> anarcat_AT_shall [ecasound]$ mkdir /tmp/b
> anarcat_AT_shall [ecasound]$ stat /tmp/b
> File: "/tmp/b"
> Size: 512 Allocated Blocks: 2 Filetype: Directory
> Mode: (0755/drwxr-xr-x) Uid: (1000/anarcat) Gid: (0/wheel)
If ecawave now creates files under /tmp/b, they are open to attacks. And
if ecawave is run as root (which is of course not recommended), a local
attack can be very dangerous.
> I guess this is not really a requisite for a temporary directory, no?
> Shouldn't kvutils use a function such as mkstemp or mkdtemp?
[...]
> http://www.FreeBSD.org/cgi/man.cgi?query=mkdtemp
Ah, mkdtemp() would be really nice, but unfortunately is bsd-specific -
at least not available in the glibc 2.1.2 I'm using.
-- http://www.eca.cx Audio software for Linux!-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request_AT_wakkanet.fi>.
This archive was generated by hypermail 2b28 : Wed Oct 10 2001 - 02:27:13 EEST