Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Debian Pureftpd Wrapper options #10

Closed
nomandera opened this issue Nov 4, 2015 · 12 comments
Closed

Debian Pureftpd Wrapper options #10

nomandera opened this issue Nov 4, 2015 · 12 comments

Comments

@nomandera
Copy link

Debians Pureftpd Wrapper has a somewhat unusual way of defining a number of settings by requiring that a bunch of files be created/edited to contain yes/no/number variables

My current non docker Pureftpd install has most of these set.

Do you have any interest if I document here what I believe are sane settings with a view to explicitly setting them in this docker?

@stilliard
Copy link
Owner

Hi anoma,
Sure if you'd like to sugest different defaults that's fine.
I have some details of the current defaults here: https://github.com/stilliard/docker-pure-ftpd#default-pure-ftpd-options-explained but please feel free to suggest additions and changes, thanks.

@nomandera
Copy link
Author

OK good. There are several more that I am not even sure can be set via switches.

Will add some more details in the next day or do.

@nomandera
Copy link
Author

@stilliard this all stems from my preference to, wherever possible, explicitly set all pureftpd options rather than inherit defaults (reducing the chance of any upstream changes sneaking in without me noticing).

It does however seem that more recent pureftpd versions can set most of the conf files via switches now however I am not sure calling the daemon with 40+ switches is sane.

To combat this currently live I have:

The following files contain YES:

AntiWarez
ChrootEveryone
CreateHomeDir
CustomerProof
Daemonize
DontResolve
IPV4Only
NoAnonymous
NoChmod
NoRename
ProhibitDotFilesRead
ProhibitDotFilesWrite

The following files contain NO:

AllowAnonymousFXP
AllowDotFiles
AllowUserFXP
AnonymousCanCreateDirs
AnonymousCantUpload
AnonymousOnly
AutoRename
BrokenClientsCompatibility
CallUploadScript
DisplayDotFiles
IPV6Only
KeepAllFiles
LogPID
NATmode
PAMAuthentication
UnixAuthentication
VerboseLog

After some digging it seems that the following config files can also exist and whilst I do not currently have these set, some look viable for sane defaults, some do not and others should definitely only be switches:

AltLog
AnonymousBandwidth
AnonymousCantUpload
AnonymousRatio
Bind
CreateHomeDir
ForcePassiveIP
FortunesFile
FSCharset
ClientCharset
LimitRecursion
LogPID
MaxClientsNumber
MaxClientsPerIP
MaxDiskUsage
MaxIdleTime
MaxLoad
MinUID
NoTruncate
PassivePortRange
PerUserLimits
Quota
SyslogFacility
TLS
TrustedGID
TrustedIP
Umask
UserBandwidth
UserRatio
LDAPConfigFile
MySQLConfigFile
PGSQLConfigFile
PureDB

I suggest that we define as many options as possible in the docker so that the FTP appliance ships with sensible defaults defined by the appliance rather than the donor OS (especially since users can just override anyway).

I am not sure the cleanest way to do this though. Historically I have just:

cd /etc/pure-ftpd/conf/
echo "yes" | tee AntiWarez ChrootEveryone CustomerProof DontResolve IPV4Only NoAnonymous

but this may not work well if at all in the DOCKERFILE and I am conscious of not wanting to make it so any subsequent changes cause a ripple effect in the shipped layers.

Update, only the following exist by default:
AltLog
FSCharset
MinUID
NoAnonymous
PAMAuthentication
PureDB
TLSCipherSuite
UnixAuthentication

@stilliard
Copy link
Owner

Hi @anoma ,
You're right this would be too much when calling the daemon.

I think alot of these setting are good, but we should be careful not to break existing implementations of this container.

Maybe we should start a new version/branch for this work so people can choose to keep using the existing version, or choose to use the newer fully configured version.

What do you think?

@nomandera
Copy link
Author

I think that is a good idea. I do not know what the branch naming would be but a default debian install and a hardened install are two completely different beasts.

I have actually been working quite hard on a new pureftpd setup here and it reminds me how many real world fixes it can benefit from.

@stilliard
Copy link
Owner

Awesome, I think a "hardened" branch would work well. I'll look into how we
expose that best for docker users. I assume we can just have a docker tag
for hardened too which could be advertised as the default on the readme and
docker hub page.

Best wishes,
from Andrew Stilliard.
On 10 Nov 2015 19:23, "anoma" [email protected] wrote:

I think that is a good idea. I do not know what the branch naming would be
but a default debian install and a hardened install are two completely
different beasts.

I have actually been working quite hard on a new pureftpd setup here and
it reminds me how many real world fixes it can benefit from.


Reply to this email directly or view it on GitHub
#10 (comment)
.

@nomandera
Copy link
Author

That makes sense. If we pay close attention to the dockerfiles we should be able to get a high percentage of layer overlap between the two branches so that download wise they should only be a few MB different at most.

@stilliard
Copy link
Owner

@anoma I've now added a new hardened branch and set the docker hub version to have this tag available too as well as any git tags added for future different versions of pure-ftpd on debian wheezy/jessie and the hardened version. Should be up on docker hub shortly.

@nomandera
Copy link
Author

Looks good to me. Coincidentally I have just completed two end to end pureftpd installs as I received a NOC hardware upgrades. I took notes during the install specifically with this new branch in mind.

How do you want to do this. One ticket per idea or one monolithic "hardering thread" perhaps with a todo list in the OP?

@stilliard
Copy link
Owner

@anoma
I guess it depends on how many changes you'd like to introduce.
I think a ticket per idea if there's not too many, but else you can build a todo list here would be fine.

@nomandera
Copy link
Author

Only a few actually. Let me do one ticket each as I review my notes so we can keep the discussion focused.

@stilliard
Copy link
Owner

thanks @anoma, that would be awesome.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants