|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
Re: Virtual local delivery agent
Subject: Re: Virtual local delivery agent
From: Andrew McNamara (andrewm
connect.com.au)
Date: Mon Jan 24 2000 - 23:36:25 CST
- Next message: Ralf Hildebrandt: "address not listed for hostname"
- Previous message: Wietse Venema: "Re: Correct way of rerouting bounce messages"
- In reply to: Wietse Venema: "Re: Virtual local delivery agent"
- Next in thread: Wietse Venema: "Re: Virtual local delivery agent"
- Next in thread: Christopher E. Brown: "Re: Virtual local delivery agent"
- Next in thread: Bryan Mawhinney: "RE: Virtual local delivery agent"
- Reply: Andrew McNamara: "Re: Virtual local delivery agent"
- Reply: Wietse Venema: "Re: Virtual local delivery agent"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
>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.
>Is there a way to get the ownership info from a trustworthy source?
I'm not sure what you mean here - my code currently does a map lookup
for mailbox path, uid and gid. My original question was how could this
be confined to prevent broken (or subverted) maps causing harm. I ended
up implementing two additional config options: base path and minimum
uid (I should also check for ".." appearing in the path that a map
lookup returns). I suspect this is the best that can be done in this
context (that being a specialised local delivery agent for virtual
mailbox hosting).
>Returning all three, 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.
>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 <bryanm
is.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.
---
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
- Next message: Ralf Hildebrandt: "address not listed for hostname"
- Previous message: Wietse Venema: "Re: Correct way of rerouting bounce messages"
- In reply to: Wietse Venema: "Re: Virtual local delivery agent"
- Next in thread: Wietse Venema: "Re: Virtual local delivery agent"
- Next in thread: Christopher E. Brown: "Re: Virtual local delivery agent"
- Next in thread: Bryan Mawhinney: "RE: Virtual local delivery agent"
- Reply: Andrew McNamara: "Re: Virtual local delivery agent"
- Reply: Wietse Venema: "Re: Virtual local delivery agent"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
This archive was generated by hypermail 2b27 : Mon Jan 24 2000 - 23:37:41 CST