[Segmentation fault] in Email::set_pop_user of /usr/local/directadmin/dataskq

[zEitEr]

Hello,

Following this guide: http://www.directadmin.com/features.php?id=1461 we have an issue with one user:

Program Location: getHomeDir : userbobProgram Location: getHomeDir : userbob : done
Program Location: getHomeDir : userbob
Program Location: getHomeDir : userbob : done
Program Location: getHomeDir : userbob
Program Location: getHomeDir : userbob : done


Program received signal SIGSEGV, Segmentation fault.
0x00000000004b4f6c in Email::set_pop_user(ConfigFile*, char const*, char const*, char const*, char const*, Config*, char const*, unsigned long long) ()
(gdb) q

If we remove temporary /usr/local/directadmin/data/users/userbob and run

/usr/local/directadmin/dataskq

all is fine, the rewrite action fails on that single user:

echo "action=rewrite&value=email_passwd" >> /usr/local/directadmin/data/task.queue

Going into details of user domains I checked all the /etc/virtual/*/passwd of the user's domains.

Amongh the other I found wrong records in one of the domain's passwd file:

email.box:!$1$JHamD****************fIHkdfspm/0

but that should be

bado:$1$lu1D****************fIHk:1762:8::/home/userbob/imap/domain.com/bado:/bin/false

I'm not sure whether or not it's OK to leave it as it is now (I mean the function set_pop_user()). Still I'd like to ask you to add a check probably to prevent the Segmentation fault.

 

[DirectAdmin Support]

The 2 column format happens when:

dovecot=1

is not set in the directadmin.conf.

If you've also added:

add_userdb_quota=1

then it should be even longer still:

fred:$1$SdbJQZ6r$R5FmKrayU3FvPksLTd.7X0:501:12::/home/username/imap/domain.com/fred/bin/false:userdb_quota_rule=*:bytes=50M

Anyway, just double check dovecot=1, eg:

cd /usr/local/directadmin
./directadmin c | grep dovecot

DA can convert it back to the long format with:

cd /usr/local/directadmin
echo "action=convert&value=todovecot&smart=yes" >> /usr/local/directadmin/data/task.queue
./dataskq d

http://www.directadmin.com/features.php?id=924

If you still get the short version, even with dovecot=1.. let me know.
Something with teh add_userdb_quota=1 might be breaking it.

If you still get the segfault, try running it through gdb, and dump us the output (or email it to us, support@da)

John

 

[zEitEr]

Thank you, John.

The question was is it OK to let dataskq to segfault in such a case or you probably could add an additional check to drop an meaningful error instead of segfault?

 

[smtalk]

zEitEr, would I be able to debug it on your system? (free of charge)

 

[zEitEr]

Martynas,

Thank you for your offer. The issue was already solved by us before posting the new thread here. Probably I'm not enough clear. So I'll try to be more specific.

For now if

/etc/virtual/domain.com/passwd

has a mix of short and long versions of records datataskq fails with segfault. That's not a big issue to strace or debug it for you, for me. Just a matter of time. My suggestion would be to add an additional check into the code of datataskq, so if it meets a short line expecting to see a long line it would output something more friendly: wrong format of the file in /etc/virtual/domain.com/passwd.

Something like this:

if (is_short($line))
{
    echo "Error. Wrong format of the file in /etc/virtual/$domain/passwd";
}

 

[DirectAdmin Support]

Thanks for the clarification.

One question on this statement

If we remove temporary /usr/local/directadmin/data/users/userbob

was the userbob folder actually removed, or was it just renamed?

I was able to duplicate a segfault when I renamed it to userbob.moved, because the home path entry from /etc/passwd was null, since the system account didn't exist.
I've added a check to ensure the system account actually works before the processing starts.

I'm not 100% sure if that was the issue, but the segfault was resolved after I added the check.

In any case, it's likely going to be a rare occurrence, as the /usr/local/directadmin/data/users/username shouldn't exist, if username doesn't exist in /etc/passwd.
But that aside, we don't like segfaults, so do appreciate the report

Fixed/pre-release binaries.

John

 

[zEitEr]

John


I'm not sure how it happened, but records for domain.com owned by userbob contained both type of lines, in other words it looked something similar to the following:

fred:$1$SdbDFJQZ6r$R5FDfdU3FvPksLTd.7X0:501:12::/home/userbob/imap/domain.com/fred/bin/false
home:$1$SADFdFJQZ6r$dfsdfU3FvPksLTd.7X0
info:$1$SdFZ6r$R5FmsfgdsgDGU3FvPksLTd.7X0
office:$1$SdDAFQZ6r$R5FmKrayDFPksLTd.7X0:501:12::/home/userbob/imap/domain.com/office/bin/false

Thus the passwd had both short and long lines at the same time, as if somebody add them manually much longer before me.


And yes, we moved directory /usr/local/directadmin/data/users/userbob to /root/userbob and re-run conversion process once more. That helped to avoid segfault as directadmin did not find the problematic user any longer and did not read its /etc/virtual/domain.com/passwd file. After that we moved /root/userbob back to its original location, checked /etc/virtual/domain.com/passwd and fixed it manually. We changed broken lines to a correct view:

fred:$1$SdbDFJQZ6r$R5FDfdU3FvPksLTd.7X0:501:12::/home/userbob/imap/domain.com/fred/bin/false
home:$1$SADFdFJQZ6r$dfsdfU3FvPksLTd.7X0:501:12::/home/userbob/imap/domain.com/home/bin/false
info:$1$SdFZ6r$R5FmsfgdsgDGU3FvPksLTd.7X0:501:12::/home/userbob/imap/domain.com/info/bin/false
office:$1$SdDAFQZ6r$R5FmKrayDFPksLTd.7X0:501:12::/home/userbob/imap/domain.com/office/bin/false

and after that no segfault and conversion process completed fine.

Thank you.

Alex.

 

[DirectAdmin Support]

I found/fixed the segfault. It should be in the pre-release section now.

John

 

[zEitEr]

Thank you, John.