
Please add a fix permissions feature in virtualmin.
Many users are using webmin file manager to alter the files, and this cause the permission of files / folders got changed to root which can cause some permission problems in ftp service, php , ...
[update] It's now available on Validate Virtual Servers -> Fix permissions
Status:
Closed (fixed)
Comments
Submitted by JamieCameron on Thu, 09/01/2011 - 17:30 Comment #1
Domain owners who use the file manager should only be accessing files with their permissions, not root ..
Are you seeing file ownership changed when non-root users are logging in?
No, of course non-root login has no problem.
I'm using root to change user's files and so it's not a bug, just a suggestion. A 'fix permission' feature in Limits and validation section of virtualmin.
All other panels have a script to reset all permissions in /home folder.
I'm currently using my own script,
Submitted by JamieCameron on Thu, 09/01/2011 - 23:07 Comment #3
Even using root to edit files shouldn't cause permissions issues .. are you finding that if you edit a file as root, its ownership is being changed?
I'd like to avoid having a button to reset permissions, as it seems like papering over the underlying problem.
The permissions are correct even using file manager. But what about using ssh or remote desktop to copy, change files , ... ?
Submitted by JamieCameron on Fri, 09/02/2011 - 16:06 Comment #5
I guess it wouldn't hurt to add this feature .. I will update this ticket when it is done.
Submitted by JamieCameron on Sat, 09/03/2011 - 00:19 Comment #6
This will be available in the next Virtualmin release, at Limits and Validation -> Validate Virtual Servers.
Submitted by Issues on Sat, 09/17/2011 - 01:22 Comment #7
Automatically closed -- issue fixed for 2 weeks with no activity.
Thank you for adding this feature.
Please add a standard chmod reset for the files/folders too. for example, /home/domain1 is chmodded wrongly to 755 ! while because of security matters it should be 750 (?) . Please do this reset for all files / folders available in /home folder ( e.g. /home/domain1/domains/sub1.domain1.com, /home/domain1/public_html, /home/domain1/tmp, ... ) Also what about a chmod 644 for files and 755 for folders available in public_html directory ?
Submitted by andreychek on Wed, 08/01/2012 - 14:29 Comment #9
Well, it's difficult to predict what permissions someone would want their files and directories set to.
For example, a lot of users use "775" on files in the public_html directory in order to allow groups to write to them, and "2775" permissions on directories for similar reasons.
Files in the Maildir directory would have different permissions though, not allowing any world or group read access.
We'll discuss all that, but setting file/directory permissions isn't as straight forward as setting the file ownerships.
Yes, the permission fix script is supposed to reset anything to it's standard state.
The standard, secure permission is 644 for a file, 755 for a folder, 750 for the domain root folder ( /home/domain1 ), ... for public_html ...
The permissions got another values in various ways, for example copy, zip, unzip, tar, ...
I just see this thread now... please dont try to fix something for me (us) that is not broken.
If you have a problem with permissions then by all means keep on using your own script locally.
I'm not too keen at all for some button/script that will "fix" permissions on my box. The permissions on my box are fine as they are and this implementation is going to 1000's or more users ...
@Ronald :
If you've seen the Validate Virtual Servers->Fix Permissions section, there's a page which you can select which user/users are going to receive the fix. It's not forced at all !
It's a good feature when you run a copy command using root to make sure everything is fine with the copied files/folders.
A fix file ownership is different from fix file permissions, so firstly its named wrong,
secondly I decide what permissions my files and folders have, not a script that I dont know of what it is doing... and I rather not find out the hard way
There must be at least an option to disable that functionality and hide it from co-admins to protect the server(s) from this fix