Version 1.34.5
Released: 2010-01-05
skip_imap_in_backups to not include email data new
Option to skip the /home/user/imap folder in the backups for the case that there is too much data. This is a global setting so either either on or off for everyone.
The internal default is:
skip_imap_in_backups=0
but if you wish too not include "imap", then set this in your directadmin.conf:
skip_imap_in_backups=1
and restart DA.
The /home/user/Maildir directory is also skipped if skip_imap_in_backups=1 is set.
secure_access_group prevents read of domains/default directory fixed
When the secure_access_group option is enabled, the directory:
/home/creator/domans/default
is not readable by the new user, so the template ends up being taken from:
/usr/local/directadmin/data/templates/default
Temporary workaround:
set /home/creator/domains to 711 instead of 710.
The completed solution consists of a change to the way the default directory is copied.
All contents will be read in as the creator, and written as the user.
The index tokenizing also applies the same way.
Internal language files not counting correct number of variables fixed
A bug was found where the number of variables was not counted correctly.
This affected entries like the following, eg:
%sSave E-Mail%s
where with the %s %s characters, the language pack txt value ended up being ignored, and the internal default was used instead.
ips are not sorted correctly with ipv6 enabled fixed
If you've got ipv6=1 in your directadmin.conf, and are using normal ipv4 IPs in your IP list, the internal sort of the list fails since the sort function for ipv6 IPs doesn't work on ipv4 IPs. This caused the binary search to fail for index lookups, since the list ends up being unsorted. The result of that is the IP cant be removed from the list, since the index lookups fails.. so you get weird behaviors.
The solution was to do an ipv4 search in the event that parsing the ipv6 address failed in the sort comparison function.
Temporary workaround is to disable ipv6 in the directadin.conf, if you don't need ipv6 addresses.
Prevent CNAME duplicate of A record fixed
If an A record exist, there is already a check for a new CNAME to prevent duplicates from being added. So if www A exists, you cannot add www CNAME. However, there was a missed check for www.domain.com. CNAME from being added, which corrupts the zone. This fix will address that case, as well as the inverse.
This check is now also done during dns merges at restore time.
Both the short and long form of the CNAME records are compared to the A records. Any matching A records are removed, on the assumption that CNAME's are always manually added, thus take priority.
user_backup_pre.sh was not aborting backup on non-zero fixed
If the user_backup_pre.sh was returning a non-zero result, the backup procses was not aborting. Added the proper abort for non-zero return code by the script, so backups are aborted.
better support for IPv6 in dns_a.conf and dns_aaaa.conf fixed
I've made a change for the default values in dns_a.conf and dns_aaaa.conf by adding the variable IS_IPV6=yes|no to the dns template tokens.
dns_a.conf now looks like:
localhost=127.0.0.1
|*if IS_IPV6!="yes"|
|DOMAIN|.=|IP|
mail=|IP|
pop=|IP|
www=|IP|
ftp=|IP|
smtp=|IP|
|*endif|
and dns_aaaa.conf looks like:
|*if IS_IPV6="yes"|
|DOMAIN|.=|IP|
mail=|IP|
pop=|IP|
www=|IP|
ftp=|IP|
smtp=|IP|
|*endif|
so that the templates only add the IP if they're supposed to, but still allow for the admin to add hardcoded defaults outside of the "if" statement, like:
mail=1.2.3.4
Security issue with control of MySQL fixed
A security issue was found with how DA controls MySQL. This is a theoretically high risk issue which could compromise your database security. It cannot be exploited by remote attackers, only by your own DA Users (in theory). Although the issue is a confirmed valid bug, other filters most likely prevented any practical exploitation of the bug (blocked characters required to effectively do anything), but it's still considered to be relevant as it's unclear if any non-blocked characters could be used (I was not able to find any, but we won't make any assumptions here). It's recommended everyone update to this version of DA to get this fix.
Thanks to Sijmen Ruwhof from www.Secundity.com for finding and reporting this issue.
check_subdomain_owner=1 gets stuck in loop fixed
Option to prevent creating subdomain of a different user.
If this feature is enabled, if a User tries to create a domain name with 3 or more periods it in, and there is no conflicting match, DA will end up in a loop.
Security check on Referer header fixed
Added a check on the Referer http header passed to DA for all requests. The value in the Referer must match the Host value that was passed during the initial login. The host value will be stored in the session file.
If a port is passed in the Referer, the port is also checked, and must match DA's currently running port.
If no referer is passed, this check is skipped. Note that most browsers have the referer header enabled by default. If it's not enabled in your case, then this check will not be able to help you and you are at higher risk of forms being posted from remote sites.
Note that this check is only done for session based logins.
Http basic auth logins used by the API are not checked since they must pass the login/pass with each request, so there is no need to verify the referer.
The default value set internally in DA is:
check_referer=1
this will not exist in your directadmin.conf.
If you wish to disable this check, add:
check_referer=0
to your directadmin.conf and restart DA.
Note that is normal to see this error in your error.log right after your update because the host value is not yet int your sessions file:
Referer host does not match your.host.com != (null)
you will have to login again to add the host value, then you'll be fine.
check_subdomain_owner to allow owner to create users with subdomains fixed
The check_subdomain_owner check will prevent any user from having a domain be the subdomain of someone elses domain.
This also means that if "admin" has admin.com, and admin is creating user.admin.com for some other user, it will throw an error caused by the check_subdomain_owner flag.
This change will allow an exception where, if the owner of the domain is creating a user, that user can have the domain owned by his creator.. but only if the creator is creating the domain during the user creation process.
If the user then deletes that domain, he won't be able to create it again with the flag turned on, since his creator isn't creating it at that point, he is.