Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: exim: users

smtp auth, NIS and lookups.

 

 

exim users RSS feed   Index | Next | Previous | View Threaded


jasper at london

Jun 24, 2009, 6:28 AM

Post #1 of 3 (785 views)
Permalink
smtp auth, NIS and lookups.

Hi,

This is Exim version 4.63 #1 built 20-Jan-2007 10:42:32 running on
Debian GNU/Linux 4.0.

I'm trying to set up plain and login authenticators with the username
and password being looked up in nis. nis uses salted md5 passwords (the
$1$salt$hash type), these are supported by the local crypt() functions.

This works:

exim4 -d+all -be '${if
crypteq{MYPASSWORD}{${extract{2}{:}{${lookup{jasper}nis{shadow.byname}}}}}}'

but in the authenticators when testing with -bh and this server_condition:

server_condition = \
${if
crypteq{MYPASSWORD}{${extract{2}{:}{${lookup{jasper}nis{shadow.byname}}}}} \
}

i get

14:21:34 8620 search_open: nis "shadow.byname"
14:21:34 8620 search_find: file="shadow.byname"
14:21:34 8620 key="jasper" partial=-1 affix=NULL starflags=0
14:21:34 8620 LRU list:
14:21:34 8620 internal_search_find: file="shadow.byname"
14:21:34 8620 type=nis key="jasper"
14:21:34 8620 file lookup required for jasper
14:21:34 8620 in shadow.byname
14:21:34 8620 lookup failed

So any idea why nis fails in the authenticator, but not expansion testing?
Attachments: jasper.vcf (0.15 KB)
  signature.asc (0.53 KB)


exim-users at spodhuis

Jun 24, 2009, 10:07 PM

Post #2 of 3 (726 views)
Permalink
Re: smtp auth, NIS and lookups. [In reply to]

On 2009-06-24 at 14:28 +0100, Jasper Wallace wrote:
> This is Exim version 4.63 #1 built 20-Jan-2007 10:42:32 running on
> Debian GNU/Linux 4.0.
>
> I'm trying to set up plain and login authenticators with the username
> and password being looked up in nis. nis uses salted md5 passwords (the
> $1$salt$hash type), these are supported by the local crypt() functions.
>
> This works:
>
> exim4 -d+all -be '${if
> crypteq{MYPASSWORD}{${extract{2}{:}{${lookup{jasper}nis{shadow.byname}}}}}}'
>
> but in the authenticators when testing with -bh and this server_condition:
>
> server_condition = \
> ${if
> crypteq{MYPASSWORD}{${extract{2}{:}{${lookup{jasper}nis{shadow.byname}}}}} \
> }
>
> i get
>
> 14:21:34 8620 search_open: nis "shadow.byname"
> 14:21:34 8620 search_find: file="shadow.byname"
> 14:21:34 8620 key="jasper" partial=-1 affix=NULL starflags=0
> 14:21:34 8620 LRU list:
> 14:21:34 8620 internal_search_find: file="shadow.byname"
> 14:21:34 8620 type=nis key="jasper"
> 14:21:34 8620 file lookup required for jasper
> 14:21:34 8620 in shadow.byname
> 14:21:34 8620 lookup failed
>
> So any idea why nis fails in the authenticator, but not expansion testing?

It's been a decade since I last saw NIS used, so I can only guess, but:

Permissions.

You're doing the testing as the invoking user, and I suspect that's root.

The authenticator will have dropped permissions to user "exim", or
somesuch -- on Debian I believe it's "exim4" and you don't have access
for the Exim user to the NIS shadow map.

Some quick searching shows that "yp_mkdb" takes the "-s" flag, which
sets a YP_SECURE key in the database which ypserv uses to prevent
querying the map unless the client source port is <1024.

-Phil

--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


jasper at london

Feb 14, 2010, 1:43 PM

Post #3 of 3 (441 views)
Permalink
Re: smtp auth, NIS and lookups. [In reply to]

Phil Pennock wrote:

On 2009-06-24 at 14:28 +0100, Jasper Wallace wrote:


This is Exim version 4.63 #1 built 20-Jan-2007 10:42:32 running on
Debian GNU/Linux 4.0.

I'm trying to set up plain and login authenticators with the username
and password being looked up in nis. nis uses salted md5 passwords (the
$1$salt$hash type), these are supported by the local crypt() functions.

This works:

exim4 -d+all -be '${if
crypteq{MYPASSWORD}{${extract{2}{:}{${lookup{jasper}nis{shadow.byname}}}}}}'

but in the authenticators when testing with -bh and this server_condition:

server_condition = \
${if
crypteq{MYPASSWORD}{${extract{2}{:}{${lookup{jasper}nis{shadow.byname}}}}} \
}

i get

14:21:34 8620 search_open: nis "shadow.byname"
14:21:34 8620 search_find: file="shadow.byname"
14:21:34 8620 key="jasper" partial=-1 affix=NULL starflags=0
14:21:34 8620 LRU list:
14:21:34 8620 internal_search_find: file="shadow.byname"
14:21:34 8620 type=nis key="jasper"
14:21:34 8620 file lookup required for jasper
14:21:34 8620 in shadow.byname
14:21:34 8620 lookup failed

So any idea why nis fails in the authenticator, but not expansion testing?


It's been a decade since I last saw NIS used, so I can only guess, but:

Permissions.

You're doing the testing as the invoking user, and I suspect that's root.

The authenticator will have dropped permissions to user "exim", or
somesuch -- on Debian I believe it's "exim4" and you don't have access
for the Exim user to the NIS shadow map.

Some quick searching shows that "yp_mkdb" takes the "-s" flag, which
sets a YP_SECURE key in the database which ypserv uses to prevent
querying the map unless the client source port is <1024.


[.Apologies for the thread necroscopy, replying to this now incase
anyone finds it in the archives]
Yes, thats exactly what the problem is. I fixed it by allowing exim to
run ypmatch via sudo with no password via adding this to /etc/sudoers:
exim ALL=NOPASSWD: /usr/bin/ypmatch

and then in the authenticators using:
server_condition = "${if and { \
{!eq{$2}{}} \
{!eq{$3}{}} \
{ or { \
{crypteq{$3}{${extract{2}{:}{${run{/usr/bin/sud
o ypmatch $2 shadow.byname}}}}} } \
{and { {eq{$2}{USERNAME}} {eq{$3}{PASSWORD}} }}
\
} \ } \
} }"

USERNAME and PASSWORD where the username and password all the clients
used until i put this in place instead.
Attachments: jasper.vcf (0.15 KB)
  signature.asc (0.53 KB)

exim users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.