Re: Getpwnam helper fix

Henrik Nordstrom wrote:
>
> Sounds like a excellent idea.
>
> To be correct the helper has to support both concurrently. The same
> system may have both shadow and non-shadow users. So how you are
> supposed to use these is that you first try with getspnam(), if that
> fails fall back on getpwnam().
>
> Not all systems have getspnam() so a new configure test may be needed.
> Also there is noticeable security implications as the helper has to be
> installed set-user-id root (or set-group-id shadow on systems using a
> shadow group) in order to be able to use getspnam(). Because of this
> it's perhaps better to make a new getspnam helper based on the getpwnam
> helper code.
>
> Regards
> Henrik

First, thanks for the fast reply.

I took a quick look on the configure tests that squid make, and didn't
saw it looking for shadow.h or the shadow suite (correct me if I'm
wrong). So i think that a simple test should suffice. And perhaps a
variable like HAVE_SHADOW_H could be added to the config.h. I didn't
knew that some systems have the 2 kind of authentication, but if you say
so, i believe. Nowadays, the majority of systems have some kind of
shadowing.

On BSD systems, the encrypted passwords are kept in /etc/master.passwd
and, much like shadow, only root can see it. But, in BSD systems, the
getpwnam function works, you only need to run the program that is
calling it as root. So, the helper, on BSD systems, must be installed
suid root. This way, the getpwnam plugin would work only on BSD systems
and systems that are POSIX compliant, but do not have shadowed
passwords. I can write a new helper using the getspnam function or can
modify the getpwnam helper to do both the authentications. I believe
that the second is the most desirable, because on the systems you
mentioned (that have both methods), only some users would authenticate
(ie. the ones that the helper you are using can authenticate).

Anyway, the helper should be run with the suid root bit set, or could
use some kind of privilege separation. The plugin i wrote does this. So
even if the OpenVPN process drop it's privileges and is run in a chroot,
users still authenticate, because my plugin does a fork() and leave a
background process running as root. And a new configure test should be
made to look for the shadow suite.

Any ideas?

The plugin i made for the OpenVPN can be found on:
http://sourceforge.net/projects/auth-passwd/

My regards,

-- 
Giancarlo Razzolini
Linux User 172199
Moleque Sem Conteudo Numero #002
Slackware Current
OpenBSD Stable
Snike Tecnologia em Informática
4386 2A6F FFD4 4D5F 5842  6EA0 7ABE BBAB 9C0E 6B85