clientmqueue permission problem ...

Hi,

Got a problem with clientmqueue permission now ... Bad day !

Here is my problem :

When using my sendmail installation through smtp port, no problems

When sending a mail from a web page (ie with invocation of sendmail by the
nobody account) got permission problem on clientmqueue

Sep 15 15:35:57 myserversendmail[13293]: NOQUEUE: SYSERR(nobody): can not
write to queue directory /var/spool/clientmqueue/ (RunAsGid=0,
required=1002): Permission denied

1002 is the smmsp group

clientmqueue permissions :

drwxrwx--- 2 smmsp smmsp 80 Sep 15 15:22 clientmqueue


sendmail permissions :

-r-xr-sr-x 1 root smmsp 610126 Sep 15 10:13 /usr/sbin/sendmail


When logging the box with the nobody account and trying to send mail with
sendmail i got :

nobody@myserver:~> /usr/sbin/sendmail -t -i xxx@xxx.xxx
WARNING: RunAsUser for MSP ignored, check group ids (egid=1002, want=100)
can not write to queue directory /var/spool/clientmqueue/ (RunAsGid=0,
required=1002): Permission denied
nobody@myserver:~>

The same error message i got when sending mail from php, except gid wanted
is different ...

I got a nother server with exactly the same permission and it work well !!!

I'm going mad !

Anybody got an idea ?

Many thanks for responses

Best regards,

Alain Deseine.

Re: clientmqueue permission problem ...

Alain Deseine wrote:

> Got a problem with clientmqueue permission now ... Bad day !

> drwxrwx--- 2 smmsp smmsp 80 Sep 15 15:22 clientmqueue

> -r-xr-sr-x 1 root smmsp 610126 Sep 15 10:13 /usr/sbin/sendmail

Use -n to list the gid as numerical value.

> WARNING: RunAsUser for MSP ignored, check group ids (egid=1002, want=100)
> can not write to queue directory /var/spool/clientmqueue/ (RunAsGid=0,
> required=1002): Permission denied

Check the the gid is correct:

grep smmsp /etc/passwd /etc/group

--
Note: please read the netiquette before posting. I will almost never
reply to top-postings which include a full copy of the previous
article(s) at the end because it's annoying, shows that the poster
is too lazy to trim his article, and it's wasting the time of all readers.

Re: clientmqueue permission problem ...

Hi,

Was not a permission problem because every thing is ok with permissions.

I've take a look to the C code (readcf.c). Apparently, there is problems
when specifying the RunAsUSer option with usernames.

If you set :

O RunAsUser=smmsp

in submit .cf, you got this error targeted :

WARNING: RunAsUser for MSP ignored, check group ids (egid=1002, want=100)

Apparently, this error is targetted because sendmail don't get the good gid
for the user !!! (bug ???). When you replace the username with the UID of
the same user :

O RunAsUser=26

The error message dissapear !!!

But the next error message continue to appear :

can not write to queue directory /var/spool/clientmqueue/ (RunAsGid=0,
required=1002): Permission denied

to workaround this problem, you should implicitly indicate the GID of the
RunAsUser option like this :

O RunAsUser=26:1002

And then the error disappear, and the mail is sent !!!

I haven't time to take a look deeper in the sendmail source code, but
apparently there is a problem retrieving GID from username, and another one
retrieving the GID of the RunAsUSer when the real user is not smmsp or root.
I think it will be valuable to review this code.

For now, my problem is solved, and i hope this post will help many people
.....

Best regards,

Alain Deseine.


"Claus Aßmann"
a écrit dans le message de news:
dgdi2k$a0m$1@obelix.informatik.uni-kiel.de...
> Alain Deseine wrote:
>
>> Got a problem with clientmqueue permission now ... Bad day !
>
>> drwxrwx--- 2 smmsp smmsp 80 Sep 15 15:22 clientmqueue
>
>> -r-xr-sr-x 1 root smmsp 610126 Sep 15 10:13 /usr/sbin/sendmail
>
> Use -n to list the gid as numerical value.
>
>> WARNING: RunAsUser for MSP ignored, check group ids (egid=1002, want=100)
>> can not write to queue directory /var/spool/clientmqueue/ (RunAsGid=0,
>> required=1002): Permission denied
>
> Check the the gid is correct:
>
> grep smmsp /etc/passwd /etc/group
>
> --
> Note: please read the netiquette before posting. I will almost never
> reply to top-postings which include a full copy of the previous
> article(s) at the end because it's annoying, shows that the poster
> is too lazy to trim his article, and it's wasting the time of all readers.