on 4/11/05 11:23 PM, Kurt Bigler <[EMAIL PROTECTED]> wrote:

> password changing via sqwebmail is failing as per this maillog entry:
>   sqwebmaild: authdaemon: s_connect() failed: Permission denied
> Searching the sqwebmail archives for the above maillog error reveals this
> advice from Sam:
>> Presuming that you"re using the latest versions of all packages: verify the
>> ownership and the permissions of the sqwebpasswd wrapper.  It should have
>> the setgid bit set, and owned by whatever userid and groupid was assigned to
>> courier-authlib.
> My sqwebpasswd seems to meet this requirement as these two directory
> listings show:
> -rwxr-sr-x  1 root  wheel    3752 Apr 11 20:23 sqwebpasswd
> -rwxr-xr-x  1 root  wheel  51860 Apr 11 00:29 authdaemond*
> assuming authdaemond's ownership is a correct reference for the "userid and
> groupid was assigned to courier-authlib".
> But I was a little surprised to see the root/wheel ownership, and this also
> contradicts what the courier-authlib INSTALL file says will happen if the
> above two options are not set and there is no previous Courier install:
>> The userid is the first userid from the following list which exists in the
>> system: courier, daemon, adm, bin, root; and the groupid is the first
>> groupid
>> from the following list which exists in the system: courier,  daemon, adm,
>> sys, root
> because I do have daemon both as a user-id and a group-id on my system.

Apparently the authdaemond is irrelevant in determining the courier-authlib
ownership.  In fact the ownership was daemon/daemon exactly as specified by
the INSTALL file, and changing the sqwebpasswd to be owned likewise resolved
the problem of not being able to change passwords from sqwebmail.

However, I'd still appreciate advice regarding a good choice for the
user/group, as I was saying....

> However, this made me wonder if there are any opinions here about "best
> practices" for courier-authlib ownership in a primarily-vpopmail situation.
> The possibility of using vpopmail/vchkpw comes to mind immediately, but
> maybe courier-authlib is a wrapper that makes this irrelevant, so that
> creating a "courier" user and group would be just as good.
> I'd also like to do things in a way that wouldn't get me in trouble if I
> later add Courier IMAP to my system.


Reply via email to