mff-uk / odcs

ODCleanStore
1 stars 11 forks source link

Filename and directory name taken from client request #1242

Closed ghost closed 9 years ago

ghost commented 10 years ago

There is possible problem with new DPU filename and directory name. Both filename and directory names on the server are derived from what the client sent in HTTP POST request as filename (which can be really any string!).

Even if we take into account, that this system will not be attacked by any hacker, regular user can hit errors in my opinion.

Consider server running on Windows machine using NTFS. According to http://en.wikipedia.org/wiki/Comparison_of_file_systems#cite_note-note-174-44 the NTFS can handle any character 'except NUL and \ / : * ? " < > |'. Consider client running Linux with ext3, uploading a:-1.1.1.jar. What happens? I don't know, probably error. Will have to test. See DPUModuleManipulator class.

But there is even more. The jarDirectory length limit in database is set to 255 characters. But there is a filesystem (ReiserFS for example) where the filename can be much longer (according to http://en.wikipedia.org/wiki/Comparison_of_file_systems it can be as long as 4096 characters). Even if the server filesystem can handle this, one will probably die on saving to the database, since directory name is derived from filename.

I would consider to leave using client sent filename to anything else except file-display-name for the user (and in the database the field would be long enough or the file-display-name would be abbreviated when saving). Let's use another file-real-name (generated random all filesystems safe string) field for the filesystem name (also stored in database).

tomas-knap commented 10 years ago

Michale, which commit solves this issues? In which feature branch?

ghost commented 10 years ago

To this time, i have not resolved this issue.

tomas-knap commented 10 years ago

Ok, than I will remove the "test that" flag

ghost commented 10 years ago

Oh, sorry for that flag.

skrchnavy commented 9 years ago

Is this requirement valid ? Shall we move it into UV/Core issues?

ghost commented 9 years ago

Move it, we should rework the naming, yes. Not from client HTTP infor (multiparf-form-data filename atribute), but from JAR artifactId, parse manifest file etc etc.

tomas-knap commented 9 years ago

Duplicates: https://github.com/UnifiedViews/Core/issues/268