On Mon, Feb 01, 1999 at 06:24:22PM +0000, Jules Bean wrote: > That solution works well for me. > > Although I'd call it /usr/lib/listar, probably. (Did we dump
That's what I meant; /usr/lib/listar/restricted-executables/ or some such. > /usr/libexec? Oh well, I'm sure there was a reason..). Apparently. I know that lots of things have executables in that location. (Majordomo, for one, which provides a good example for me to follow). I'd think of /usr/sbin, but it doesn't allow for this sort of trickery. > I wouldn't have those +ws in place, though, unless they're necessary. Well the -w can be taken off, but as I said, it does need to be setuid. > IMHO, this is the wrong solution, but it's a fundamental problem. The > security model I'd prefer would involve listar running as a daemon > continually, and giving it a secure way of telling that incoming requests > (on some unix-domain sockets) came from authorised systems. Probably This would involve adding this sort of unix-domain socket support into all the MTAs in use -- a problem, definately. I am satisfied with having this sort of thing setuid/setgid and only executable by the mail daemon. However, what bothers me is the necessity of placing it in a separate directory as a kludge to get proper (effective) permissions for it. What I'd like to see is true ACL support in the Linux filesystem; such support would, if done right, obliviate the need to do these sorts of hackish tricks.
