OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Postfix Archives: Re: Virtual local delivery agent

Re: Virtual local delivery agent

Subject: Re: Virtual local delivery agent
From: Wietse Venema (wietseporcupine.org)
Date: Tue Jan 25 2000 - 19:54:37 CST

Andrew McNamara:
> >It indeed gives me the heebee-jeebies when software derives write
> >privileges from the very file it wants to write to. Doing so means
> >Postfix has carte blanche to clobber any file on the system. I'd
> >be much happier if Postfix knows write privileges ahead of time.
>
> Indeed. I'm prepared to accept it in my context as the paths given to
> the hacked local are carefully controlled, but I don't think it's
> acceptable where general purpose maps are involved (and unsuspecting
> admins may be configuring it). My solution was to write a custom map
> that stat'ed the parent directory to get path, uid and gid, which my
> new virtual local used. I don't intend to distribute this map.

Using the parent directory owner's privileges is already a lot
better than using those of the file owner, but for general use it
would have to be constrained (no root, no postfix).

> >Returning [path uid gid], separated by a suitable delimiter, would be
> >an attractive possibility.
>
> This was my original thought, but I was worried that people with
> existing setups (LDAP?) wouldn't be able to return the delimited data.

And for a proper job, Postfix would have to support multi-valued
lookup results.

> >But Postfix really needs a more generic table lookup interface
> >where the result of lookup is an attribute list with named fields.
>
> Yes - which would also be useful for the new, more powerful, transport
> map. Bryan Mawhinney <bryanmis.co.za> made a reasonable suggestion
> (return a list with key=value pairs). I'll have to give some thought to
> how this could be implemented in a clean backward compatible manner
> (would probably require duplicating the existing API - yuck).
>
> If this was implemented, a "join" map-type would be desirable - the
> idea being that it would look the key up in a number of separate
> old-style maps and join the result together returning the new key=value
> response.
>
> Another alternative to a list is to define a character as the "official"
> delimiter (say colon), join multiple fields/columns in maps that have
> them (LDAP, SQL), and do the splitting in the code that uses the maps.
> Bad luck if you need to use the delimiter character for legitimate
> data.

That's the problem with in-band signaling.

        Wietse

> ---
> Andrew McNamara (System Architect)
>
> connect.com.au Pty Ltd
> Lvl 3, 213 Miller St, North Sydney, NSW 2060, Australia
> Phone: +61 2 9409 2117, Fax: +61 2 9409 2111
>
>
>

This archive was generated by hypermail 2b27 : Tue Jan 25 2000 - 19:56:36 CST