On Mon, 1 Feb 1999, John Goerzen wrote: > > The solution that I have come up with is to create a special directory in > its /usr/lib area: > > drwxrwx--- listar.daemon restricted-executables/ > > Then, in there, have the binary: > > -rwsrwsr-x listar.listar listar > > How does that sound to everyone? This achieves appropriate security (only > executable by MTAs [technically, the daemon group]) but still stuid and > stgid appropriately. The downside is that the 4.9 doctrine is that people > should be given read access as much as possible, but that isn't really > possible here. The world-readable and -executable bits on the binary don't > make a different to others; they can't even get to that area.
That solution works well for me. Although I'd call it /usr/lib/listar, probably. (Did we dump /usr/libexec? Oh well, I'm sure there was a reason..). I wouldn't have those +ws in place, though, unless they're necessary. Aside: 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 using a large number of key-pairs. This is definitely another problem for another day, though. Jules /----------------+-------------------------------+---------------------\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd | | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED] | TW9 2TF *UK* | +----------------+-------------------------------+---------------------+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \----------------------------------------------------------------------/
