Karl Pielorz wrote:
>Warner Losh wrote:
>> If advisory locks won't work (and they almost always will for things
>> like this), then you could walk the process tree. For all processes
>> that aren't suspended or yourself, send a SIGSTOP, keep a list.
>I don't think advisory locks will work - the other process is sendmail... I
>have to keep it from opening any of it's config files, whilst I 'rename' out
>of place the old ones (keeping any fd's to them intact) and rename in the new
>ones...
Warning, here be dragons...
You could try replacing sendmail (using mailer.conf) with a script
that sets LD_PRELOAD and then execs sendmail. Then you have to write
a little shared lib to wrap some system calls. If you are lucky,
wrapping open() will be sufficient. In your wrapper function, you
should have the opportunity to use any of a number of mutual exclusion
schemes, including advisory locking.
Some sessions with truss/ktrace and some studying of the sendmail
source may be necessary to get it right, but this is something I'd
definitely check out.
A wrapper for open could look like:
#define open __hide_open_prototype
#include <sys/types.h>
#include <fcntl.h>
#include <unistd.h>
#undef open
int
open(const char *path, int flags, mode_t mode)
{
if (/* path is a file to be protected */) {
/* do something */
/* and beware of calling open() recursively */
}
return _open(path, flags, mode);
}
Compile with "cc -shared -o open.so -fpic open.c"
Of course, this still may not help much when sendmail has opened some
of its files, and you then change all of them, which might lead to
inconsistencies.
$.02,
/Mikko
--
Mikko Työläjä[EMAIL PROTECTED]
RSA Security
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
