Bug: move_domain.sh doesn't set the permissions correctly

From one user to another, on the same server.
Also, IPs don't change or are not added, which means that you end up with ghost IPs.
 
How did you do that? I didn't see in directadmin any new feature to do it via web-interface.
Is it a 3rd-party script?
 
Just to be sure, post your result for

Code: 
/usr/local/directadmin/directadmin c | grep apache_public_html | cut -d= -f2
 
The result is 1, because it's the default and with that value, the group should be "apache" and it's not, thus the bug report.
 
Hello,

To clarify the apache_public_html=1 option is old old old.. and I don't really recommend mixing it with the secure_access_group option. (these are 2 different settings)

If you're using the secure_access_group option then you don't need apache group on the public_html, because /home/username is chmod 750 user:access, where the apache user is in the "access" group, thus that's where it's locked down.. way up at /home/user, and not down at the public_html level (except Admin/Resellers, it's at /home/reseller/domains due to backup directories)


In any case, if the apache_public_html is set to 1, then the move_domain.sh should still respect it...

I did some testing, and found that the code for this is already set in the move_domain.sh script. When I tested, the public_html directory did end up chgrp apache as expected...

Is 1.37.0 on this box? Which OS version? (perhaps it's not correctly linked in our NFS on our build system for that OS, and you've got an older version of the script)

As for the IPs not being updated, that is a bug. I've just added some code to handle the main cases for single IPs. If the domain had multiple IPs, then it's not smart enough to figure that out completely (the dns zone will have leftover ghosted IPs)

John
 
Hello John,

To clarify the apache_public_html=1 option is old old old.. and I don't really recommend mixing it with the secure_access_group option. (these are 2 different settings)
Click to expand...

It's still the default in DA if it's not defined in directadmin.conf, so, maybe the default value should be changed then?
Also, there is no mention of changes that need to be made to that value on the help page about "secure access group"
http://www.directadmin.com/features.php?id=961

If you're using the secure_access_group option then you don't need apache group on the public_html, because /home/username is chmod 750 user:access, where the apache user is in the "access" group, thus that's where it's locked down.. way up at /home/user, and not down at the public_html level (except Admin/Resellers, it's at /home/reseller/domains due to backup directories)
Click to expand...
This doesn't work very well with open base_dir and includes (when files are called using relative paths I think). Sites were broken until I changed ownership.

The reseller permissions were not correct in my case. /home/reseller/domains was 755. I ran the permissions script and it fixed it.

I did some testing, and found that the code for this is already set in the move_domain.sh script. When I tested, the public_html directory did end up chgrp apache as expected...
Click to expand...
The code changes the value for the top folder, but doesn't do it recursively, so sites break.

Box is FreeBSD 8.1, running 1.37.0.

OK about the IPs. It's not that difficult to remove the ghosted IPs (although would be nice to have DA do it all ;)), but it's trickier to add the new IP since the system already believes it's using it.
 
Hello,

Thanks, I've added a mentioned about it in the id=961 guide.

Using them both at the same time shouldn't hurt anything, it's just redundant since the apache user is in the access group.
This doesn't work very well with open base_dir and includes (when files are called using relative paths I think). Sites were broken until I changed ownership.
Click to expand...
This would be a head scratcher... can you paste any errors from the scripts? I'm not seeing how it would make a difference at what level the 750 is set, as if a process has access to a path, assuming it's 755 all the way down below it (or 750 with apache group), it shouldn't matter.

John
 
The code changes the value for the top folder, but doesn't do it recursively, so sites break.
Click to expand...
DA only set's one directory to be chgrp apache (or chgrp access with secure_access_group). Any files that end up with an apache group would have been set that way via the system (based on it's parent permissions perhaps), or via php upload... If you're referring to those files, then yes, they would break.. the script doesn't account for apache owned files added by clients... it would be something that would need to be looked at (the level of complexity goes up with this type of check). FYI, using suPhp wouldn't be affected by this.

John
 
Using them both at the same time shouldn't hurt anything, it's just redundant since the apache user is in the access group.
Click to expand...
I think there is some missing documentation regarding the permissions of public_html, apparently "apache_public_html" trumps "secure_access_group".

apache_public_html=0, secure_access_group=null
username:username, 755, not secure

apache_public_html=1, secure_access_group=null
username:apache, 750, not secure enough

apache_public_html=0, secure_access_group=access
username:username, 755, secure

apache_public_html=1, secure_access_group=access
username:apache, 750 (top folder)

When switching to apache_public_html=0, will the access group script reset the rwx permissions?

DirectAdmin Support said:
This would be a head scratcher... can you paste any errors from the scripts? I'm not seeing how it would make a difference at what level the 750 is set, as if a process has access to a path, assuming it's 755 all the way down below it (or 750 with apache group), it shouldn't matter.
Click to expand...

DA only set's one directory to be chgrp apache (or chgrp access with secure_access_group). Any files that end up with an apache group would have been set that way via the system (based on it's parent permissions perhaps), or via php upload... If you're referring to those files, then yes, they would break.. the script doesn't account for apache owned files added by clients... it would be something that would need to be looked at (the level of complexity goes up with this type of check). FYI, using suPhp wouldn't be affected by this.
Click to expand...
I'm doing some tests and will paste my findings. I think it's a problem for apps that allow plugins, like Wordpress.
 
Last edited:
There is another bug...
When adding a domain from the cp with apache_public_html=0, secure_access_group=access, the result for public_html is:
username:username, 755

When moving a domain, with the same settings, the result is:
username:username, 750

750 is wrong, it will prevent sites from working properly.
 
Last edited:
After having done some tests (with open_basedir off), I can see that:
-Some folders that need write access can be chrgped to "access" instead of having to use the dreaded 777
-Some folders need to have their permissions changed if they were xx0
 
Last edited:
You must log in or register to reply here.
Back
Top