Hide Hidden Files - Server Configuration

[warpandas]

Hi there.

I looked around in the configuration settings.. is this possible?

I would like to hide hidden files for anyone that connects to my server. I have the latest version of FileZilla FTP Server for Windows (0.9.29 beta)

[botg]

Of course not, hiding files is a sure indication of a broken server.

[warpandas]

You mean like how Serv-U had the option of hiding hidden files?

[warpandas]

bump

[boco]

A standards-compliant server mustn't hide any files from the user. Only share files and directories that users should see.

[redleg]

A standards-compliant server mustn't hide any files from the user. Only share files and directories that users should see.

I have an issue that I believe falls into the second category you mention. In my setup with FZ029b at server root I have /admin, /incoming and /pub. I have set list directories from root for users on /incoming and /pub (and no list for /admin, which users cannot see). What I desire is to have a 'blind' write /incoming directory, iow, I want users to see the /incoming directory exists and be able to write/append files to it but not to read nor list contents of the directory. I swear I was able to do this on a similar setup years ago...

Is this possible or does it fall into category #1 above? <g>

[argrithmag]

A standards-compliant server mustn't hide any files from the user. Only share files and directories that users should see.

Isn't that the idea behind "hidden" files? Those files aren't shared with the ftp user? I've recently started using this Server because GuildFtpd seems to be a dead server (no updates in years and 1.0 is in a perpetual "beta user only" mode).

I'd rather not create separate directories and copy files over to those directories that i want the user to only see. I'd rather just toggle a flag for a user/group and say that they globally can or can't view "hidden" files.


Thanks

[botg]

A lazy administrator is not an excuse to create bad servers.

[redleg]

A lazy administrator is not an excuse to create bad servers.

<BEG> I beg to differ as some of us are not lazy... how about my issue "What I desire is to have a 'blind' write /incoming directory, iow, I want users to see the /incoming directory exists and be able to write/append files to it but not to read nor list contents of the directory."

many FTP servers do this for incoming files, especially anti-malware submits where users can upload to but no one is permitted to read nor list directory contents. I want users to see there is an /incoming directory and write to it but not "enter" it and look around. It is where uploads go, until scanned and in true vouchsafe manner once done will be moved to an appropriate directory in the greater /pub listing where the general public can access and d/l at will.

(I still thinks this example falls neatly into category #1 by Boco's prior post, no?:)

btw, I am not complaining, quite the opposite I have nothing but the greatest respect for you Tim, you have provided something for free that IMO is unparalleled in the field- you have always gotten my SF vote as well as a small donation some time ago. I've been away from the server scene for a couple years and damn if your client and server have matured very nicely! Thank you, sincerely.

[boco]

This is not possible with Filezilla Server. Any directory that doesn't have the LIST permission set is invisible in the directory tree.

Note that I'm not using Filezilla Server anymore. My experiences could be a bit rusty.

[redleg]

This is not possible with Filezilla Server. Any directory that doesn't have the LIST permission set is invisible in the directory tree.

That is what I am experiencing, I swear it would LIST directories in / (root tree) but didn't used to LIST files contained inside directories w/out READ and/or LIST permissions when I ran FZserver years ago for F&F. Directories inside /incoming do not have LIST permission, hence they are quite invisible- I will just move files to a temp directory inside until scanned and ready for prime time. I am probably confusing my recollections of it all and just thinking of something I always wanted to see.. <g>
Maybe I am wrapped around the wrong idea but shouldn't files be invisible if/when a directory does not grant READ permission? as it is, no one can d/l files from the /incoming directory nor can they see directories inside /incoming, but they get to see the files contained in /incoming... lol, ok, I am repeating myself- just looking at my logs and got some uploads to /incoming and user attempted to d/l a file not moved yet, so that is working nicely..

Thanks for the reply Boco and your work on the project and these here forums! dang, you fellers are kept pretty busy answering the same questions everyday. Have a good one.

[da chicken]

A blind file drop is a bad security mechanism. It's just plainly a bad mechanism as it prohibits things like upload resume and basic file management. If users need to be able to upload files privately with FTP, they need to use the built-in mechanism in FTP for doing that. They should be given user accounts.

Remember: Just because it can be done doesn't mean it should be done.

[redleg]

A blind file drop is a bad security mechanism. It's just plainly a bad mechanism as it prohibits things like upload resume and basic file management. If users need to be able to upload files privately with FTP, they need to use the built-in mechanism in FTP for doing that. They should be given user accounts.

What you consider a bad security mechanism (blind file drop) I consider a fair quality assurance/check mechanism and if anything wrt to security it is only to protect general population/users from downloading before admin has an opportunity to check and move file to appropriate directory. My circumstance has nothing to do with the need to upload files privately it is driven out of desire to have a central file repository that gets a "seal of approval" from admin as a vouchsafe mechanism with admin assurance the files are clean of malware before access by everyone is granted. As for using user accounts to control this- I know that can be done and quite easily with FZS, but it is not what I want to do. It is a generic user/pass setup with limited WRITE/APPEND/MKDIR permissions and no DELETE rights anywhere- that will come later (with user accounts:)

about the resume issue, if APPEND permission is granted (along with WRITE) I do not see how resume would not work even if they cannot see directory contents, their FTPclient starting the upload will know what to do. I know there are blind write directories out there, that do exactly what I desire to do, I assume they are unix based servers or perhaps some of the other flavors for windows, none of which interest me...

Remember: Just because it can be done doesn't mean it should be done.

lol, true... but in this case, I feel it is a good service to provide my users some QA/QC on what they d/l from my server at the same time allow for user contributed files- which must be placed in "quarantine" or something until I can scan, categorize and then place them in the right place.

Thanks for the response da chicken, I am toying with a lot of ideas to put together a decent free service for a group of us like-minded security and privacy enthusiasts and goodly folk I consider friends and family. FTP is just the beginning of it, basically until I get any bugs worked out, then migrate to FTPES only, user accounts for elevated privileges (or anon for basic access) and on to SFTP with some port-forwarding rights (different server, same box) and eventually move the whole thing to TOR hidden services or somesuch similar..

[da chicken]

Most FTP daemons allow for directories to be set up for blind drop or blind get, but it's not always a feature. Often it's just an artifact of how permissions settings work. They can be made to function in that way, but it was never designed with that in mind.

The primary problem with a blind drop is that you either bar append and overwrite, or you deal with the fact that filename collisions will occur by accident. Alice might upload myfile.zip that's 10MB, and then Bob can come along and upload myfile.zip that's 15 MB and it gets appended, probably destroying both files. The FTP server can't even tell the difference between Alice and Bob because they're using the same user account.

Personally, I suggest granting LIST and denying READ (and APPEND if you can to prevent malicious collisions because of the Alice and Bob problem with one account). Sure, you can have a list of filenames, you just can't access the files.

I'd prefer to make users get individual accounts, even if it's through an automated web form in the way you register for a forum. On a Unix system, you can then still have a global file drop by making the default permissions for the upload or incoming folder be 200 (user write only).

[botg]

Good security works this way: Always assume your enemy knows everything, even which files there are even if he cannot see them. The only thing that keeps your enemy at bay is your long and complex secret. (Password, private key and the likes).