Two questions:
- Is it more reasonable to have the /etc/proftpd.conf file say:
[size=2]Umask 0027[/size]
than the current value of 022? This would (1) specify set-user-ID, set-group-ID, and the "sticky bit"; and, (2) turn off unintentional "other" read access. Are there any reasons to not do this?
- In cases where domains within an account may rely on sharing via group permissions, I presently have to create .ftpaccess files with content such as:
[size=2]Umask 0007[/size]
I always wind up putting this as:
[size=2]/home/
account/domains/
domainname/.ftpaccess[/size]
Does Virtualmin have any capability of managing .ftpaccess files?
You have to be very specific about your OS, version, and package when talking about proftpd. It's different everywhere, and we very often aren't the source for it (it comes from the OS standard repos on most distributions, but a couple don't have it, so we provide it). ;-)
So, are we talking about CentOS/RHEL 5?
I seem to recall that there is some support for a system-wide ftpaccess file in Virtualmin. But it's a very vague recollection. I'll have to do some digging.
--
Check out the forum guidelines!
Two servers:
ProFTPD 1.3.1 on Fedora 7 (proftpd-1.3.1-2.fc7), 32-bit
ProFTPD 1.3.1 on Fedora 10 (proftpd-1.3.1-8.fc10.x86_64), 64-bit
/etc/proftpd.conf default:
Umask 022
Webmin interface:
Webmin > Servers > ProFTPD Server > Virtual Servers Default server > Files and Directories > New file umask
Which shows:
New file umask: * Octal mask 022 (Default unselected)
New directory mask: * Default (Octal mask unselected)
So, really the only question is: since Virtualmin users UIDs and GIDs for permission control, is there any reason to allow "other" permissions at all on a public-facing production system? If the answer is "no," then it would seem that reasonable defaults would be:
New file umask: * Octal mask 0027
New directory mask: * Default
Note that I'm explicitly specifying the setUID/setGID/sticky first octal value to 0.
Lastly, the /etc/bashrc and /etc/profile should also be updated to match whatever value is being used. And, cron jobs get their umask from the environment in which cron is started (e.g., /etc/rc.d/init.d/crond), so either the umask should be specified there (in a bracketed way so as to not damage the umask for other startup processes) or individual cron jobs should specify the wanted umask. I think it would be safer to have it done only for cronjobs that are managed by Webmin/Virtualmin.