DirectAdmin v.1.38 released

D

ditto

Verified User
Joined
Apr 27, 2009
Messages
2,577
DirectAdmin v.1.38 is now released. Here is changelog: http://www.directadmin.com/versions.php?version=1.380000

There is a few security improvements described here: "Important Security Changes" http://www.directadmin.com/features.php?id=1177

secure_access_group=access
check_subdomain_owner=1

are now going to be enabled by default for new installs.
These values are set in the data/templates/directadmin.conf.

Existing installs will not be affected. This only applies to new installs using 1.37.1 at install time.

Also, the script:
/usr/local/directadmin/scripts/custombuild.sh

will now run:

chown webapps:apache /var/www
chmod 550 /var/www

chgrp apache /usr/bin/perl
chmod 705 /usr/bin/perl

to increase security.
The scripts/custombuild.sh is also only called at install time, so feel free to make these changes for existing install if you wish.
Click to expand...

Question 1: If I add secure_access_group=access to directadmin.conf, what consequence will this have on my server? Is there anything else I need to do in order for this to work correct?

Question 2: About the descriptions under "Also, the script:...", what is the complete commands to make these change on a existing install?
 
Hello,

1) If you wish to have secure_access_group=access on an existing box, add it to your directadmin.conf, then run:
Code: 
echo "action=rewrite&value=secure_access_group" >> /usr/local/directadmin/data/task.queue
and this will set all your existing Users to the new format. (changes /home/user for Users and /home/reseller/domains for Admins/Resellers)

2)
Code: 
chown webapps:apache /var/www
chmod 550 /var/www

chgrp apache /usr/bin/perl
chmod 705 /usr/bin/perl
Official 1.38.0 announcement thread

John
 
John ive an important info for you to add to that help

you need to edit httpd.conf
Code: 
nano /etc/httpd/conf/httpd.conf

and change

Code: 
Group apache

to

Code: 
Group access

Ive noticed that all subdomains arent working without this edit.

Regards
 
Other thing:

Code: 
chown webapps:access /var/www/

Using webapps:apache doesnt work (with the change at httpd.conf)

Regards
 
SeLLeRoNe said:
Code: 
chown webapps:access /var/www/
Click to expand...
I'm not sure where that command came from, but it's not correct. It should be webapps:apache, and not webapps:access.

The secure access group "access" is something totally different and in no way related to /var/www.

John
 
but in this way is working... other way in httpd.conf and /var/www permission or subdomains or phpmyadmin wasnt working at all..
 
Hello,

It's likely a permission error somewhere else, only discovered by the recent change.

Which OS version is this on? (also 32-bit or 64-bit)
I'm guessing it's php in the default CLI mode, and not suPhp?

The "apache" user should be in the "access" group, as well as the apache group, thus it wouldn't make a difference... (assuming things are setup correctly).

Check this:
Code: 
freebsd8-64# [b]id apache[/b]
uid=1003(apache) gid=1003(apache) groups=1003(apache),1008(access)
freebsd8-64# [b]grep access /etc/group[/b]
access:*:1008:apache,nobody,mail,majordomo,daemon
freebsd8-64#

As for subdomains, they work the same way as normal domains.. If it was a secure_access_group issue, then everything, including domains, would be broken. Make sure all paths are chowned to the User (owner), set to 755, and readable by the apache user. Also, a missing index.html can generate the forbidden error.

John
 
Hi, is a CentOS 5.5 64Bit.

The subdomains was working till the echo i made for access group.

All file had (ive checked) user:user as owner and im using PHP CLI and mod_ruid

Code: 
>id apache
uid=100(apache) gid=501(apache) gruppi=501(apache),631(access)

Code: 
>grep access /etc/group
access:x:631:apache,nobody,mail,majordomo,daemon

this is the /var/www directory
Code: 
dr-xr-x---  9 webapps access  4096 19 dic 00:34 www

and this is the /var/www/html/
Code: 
drwxr-xr-x  4 webapps webapps  4096 18 mar 10:41 html

Code: 
>cat /etc/httpd/conf/httpd.conf | grep Group
Group access

This way is working, othe way doesnt.. want me to send login data?

Regards
 
Ah, mod_ruid may be a factor as I've not done any testing with it; I'm not sure what it needs/how it works.

Also, apache may need to be restarted as mentioned in the documentation. We noticed some very strange caching going on (or what we believe to be caching), where the services didn't correctly re-read the permissions until they were restarted.

I'd be happy to take a look if you'd like, but I'm not too farmiliar with mod_ruid and exactly how it works, so am not sure if it's playing a role, or if it needs any special settings (perhaps, exactly as you've already done). If mod_ruid has a non-privileged user it runs as before changing to a user, then that non-privileged user would just need to be added to the access group to make it work.

John
 
And is not dangerous add everyuser to access group?

Ive noticed that now seems to be working with your settings...

So maybe was the chache problem you alraedy sayd.. but strange.. i had restarted apache at least 10time for make all test with user/group...

Thanks
 
Noticed that you edited virtual_host2_sub and secure_sub confs cause was missconfigurated for mod_ruid.

Thanks a lot for figure out my problem totally not related to da update as i supposed.

Regards
 
And is not dangerous add everyuser to access group?
Click to expand...
It is dangerous to add DA User's to the access group. It should only contain the preset list of system accounts. Only if apache was running as some other username with mod_ruid would adding that "other" username to the access group have applied. Since it was found to be unrelated, the access group should remain as it is currently.

John
 
That I cannot explain, I'm not familiar enough with mod_ruid to know. It's likely something to do with /home/user being set to 750 instead of 711, perhaps an unprivileged user couldn't read something, I'm really not sure.

What I can say, is that as you tighten security, anything that isn't as it should be will quickly show up since the number of exceptions for something to work, quickly decreases. But that's how it becomes more secure.. as attackers/hackers also have far fewer options, lowering the chance of their success.

John
 
As I understand it, mod_ruid2 runs http as the username. So the username needs directory access. However, it may be that the main apache user needs access as well.

Jeff
 
the problem wasnt on main website but just on subdomains cause virtual_host2_sub.conf was missconfigured without the mod_ruid edits that was needed to modruid to work.

Regards
 
hi i install da 1.38 on new server centos 5.5 64bit

i have some problem

why domain priview can't use ?

http://ip/~user/

i have apache error with

[Thu Mar 24 18:23:55 2011] [crit] [client 180.183.113.169] (13)Permission denied: /home/sfcutetk/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable

but in user don't have anything with .htaceess

please help to fix

Thank
 
Hello,

I'm not sure that this error is specific to this new version of DA, but in any case, the /~username access method points to /home/user/public_html, which should be a symbolic link. Why exactly the error is looking in /home/user, I'm not too sure, but check permissions:
Code: 
cd /home
ls -lad sfcutetk
cd sfcutetk
ls -la .htaccess
ls -la public_html
John
 
You must log in or register to reply here.
Back
Top