Is original_filename method in ActionDispatch::Http::UploadedFile safe to use to save as file in host system, without further sanitize it?
Looking at the source, it doesn't look like they do any checking of the filename, so unless they do it somewhere else (which would be bad design and thus unlike the Rails team), the real question is: what harm can a filename do? The only cases I can think of that it might be possible to use it maliciously is:
if the file is named ".". Those can be hard to delete if you actually succeed in creating them. I doubt that Ruby would let you save a file by that name, you can try it and see. If it doesn't, this this point can be ignored.
or maybe a really long name might cause a buffer overflow somewhere deeper in the API code of the OS.
Note that neither of those should be a problem. OSes try to make it impossible to create . files, but I've seen it done. And since (most?) filesystems already have a max filename limit, they should just error or truncate the file for you; truncating yourself is a borderline paranoid measure to protect against buffer overflow exploits that may be found in the OS's API code in the future. Such an exploit is very unlikely to exist.
So, if you really want to, just check for these two cases and you should be okay. You might want to do this by subclassing the UploadedFile class and adding the functionality that, if the name is "." or "..", then you just give it a random name; and if it is over, say 100 chars, then truncate it.
But I would say that neither of these are likely enough to warrant the introduction of a nonstandard class into your code base. I would just try saving the file by the given name and depend on the underlying file saving API to catch errors, check for said errors, and report them back to the user.
Related
In vulkan.h, every instance of VkAccessFlagBits appears in a pair that contains a srcAccessMask and a dstAccessMask:
VkAccessFlags srcAccessMask;
VkAccessFlags dstAccessMask;
In every case, according to my understanding, the purpose of these masks is to help designate two sets of operations, such that results of operations in the first set will be visible to operations in the second set. For instance, write operations occurring prior to a barrier should not get hung up in caches but should instead propagate all the way to locations from which they can be read after the barrier. Or something like that.
The access flags come in both READ and WRITE forms:
/* ... */
VK_ACCESS_SHADER_READ_BIT = 0x00000020,
VK_ACCESS_SHADER_WRITE_BIT = 0x00000040,
VK_ACCESS_COLOR_ATTACHMENT_READ_BIT = 0x00000080,
VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT = 0x00000100,
/* ... */
But it seems to me that srcAccessMask should probably always be some sort of VK_ACCESS_*_WRITE_BIT combination, while dstAccessMask should always be a combination of VK_ACCESS_*_READ_BIT values. If that is true, then the READ/WRITE distinction is identical to and implicit in the src/dst distinction, and so it should be good enough to just have VK_ACCESS_SHADER_BIT etc., without READ_ or WRITE_ variants.
Why are there READ_ and WRITE_ variants, then? Is it ever useful to specify that some read operations must fully complete before some other operations have begun? Note that all operations using VkAccessFlagBits produce (I think) execution dependencies as well as memory dependencies. It seems to me that the execution dependencies should be good enough to prevent earlier reads from receiving values written by later writes.
While writing this question I encountered a statement in the Vulkan specification that provides at least part of an answer:
Memory dependencies are used to solve data hazards, e.g. to ensure that write operations are visible to subsequent read operations (read-after-write hazard), as well as write-after-write hazards. Write-after-read and read-after-read hazards only require execution dependencies to synchronize.
This is from the section 6.4. Execution And Memory Dependencies. Also, from earlier in that section:
The application must use memory dependencies to make writes visible before subsequent reads can rely on them, and before subsequent writes can overwrite them. Failure to do so causes the result of the reads to be undefined, and the order of writes to be undefined.
From this I surmise that, yes, the execution dependencies produced by the Vulkan commands that involve these access flags probably do free you from ever having to put a VK_ACCESS_*_READ_BIT into a srcAccessMask field--but that you might in fact want to have READ_ flags, WRITE_ flags, or both in some of your dstAccessMask fields, because apparently it's possible to use an explicit dependency to prevent read-after-write hazards in such a way that write-after-write hazards are NOT prevented. (And maybe vice-versa?)
Like, maybe your Vulkan will sometimes decide that a write does not actually need to be propagated all the way through a particular cache to its final specified destination for the sake of a subsequent read operation, IF Vulkan happens to know that that read operation will simply read from that same cache, saving some time? But then a second write might happen, and write to a different cache, and there'll be two caches left in a race (with the choice of winner undefined) to send their two values to the same spot. Or something? Maybe my mental model of these caches is entirely wrong.
It is fairly solidly established, at least, that memory barriers are confusing.
Let's go over all the possibilities:
read–read — well yeah that one is pretty useless. Khronos seems to agree #131 it is pointless value in src (basically equivalent to 0).
read–write — execution dependency should be sufficient to synchronize without this. Khronos seems to agree #131 it is pointless value in src (basically equivalent to 0).
write–read — that's the obvious and most common one.
write–write — similar reason to write–read above. Without it the order of the writes would be undefined. It is a bit pointless for most situations to write something you haven't even read in between. But hey, now you have a way to synchronize it.
You can provide bitmask of more of these masks to both src and dst. In which case it makes sense to have both masks for driver to sort the dependencies out for you. (I don't expect performance overhead from this on API level, so it is allowed as convenience)
From API design perspective, it could mean adding different enum for srcAccess. But perhaps _READ variants could just be forbidden in srcAccess through "Valid Usage", making this argument weak. The src == READ variant might have been kept, because it is benign.
I know my question is rather generic (and it looks like "please do all of my work for me"), so let me make it somewhat clearer: I'm - more or less - a COBOL beginner, the only thing I've done with it so far was a small FastCGI application for a single-serving page, just to have done something with it.
Now I'm considering to write a small file server in GnuCOBOL so I have something real to work with. I tend to learn new languages by writing stuff in them. While I do have an idea about how to read and process a specific file now, I still could need a clue about how I can collect and handle a specified directory's contents.
Sadly, the system calls C$LIST-DIRECTORY,x"91" function 69, CBL_DIR_SCAN_START and its sibling methods are still on the GnuCOBOL Wish List, so I can't just adapt existing solutions from the commercial COBOLs. I'm somewhat lost here.
call "system" using "dir /b > fileslist.txt" end-call
And then read in the listing file ...
Does rails have a way to implement read streams like Node js for file reading?
i.e.
fs.createReadStream(__dirname + '/data.txt');
as apposed to
fs.readFile(__dirname + '/data.txt');
Where I see ruby has
file = File.new("data.txt")
I am unsure of the equivalent in ruby/rails for creating a stream and would like to know if this is possible. The reasons I ask is for memory management as a stream will be delivered piece by piece as apposed to one whole file.
If you want to read a file in Ruby piece-by-piece, there are a host of methods available to you.
IO#each_line/IO::foreach, also implemented in File to iterate over each line of the file. Neither reads the whole file into memory; instead, both simply read up until the next newline, return, and pause reading, barring a possible buffer.
IO#read/IO::read takes a length parameter, which allows you to specify for it to read up to length bytes from the file. This will only read that many, and not the whole thing.
IO::binread does the same as IO::read, but will open the file in binary mode.
IO#readpartial appears to be very similar or identical to IO#read, but is also worth looking at.
IO#getc and IO#gets both read from the file until they reach the end of what they'll return, as far as I can tell.
There are several more that I'm looking for right now.
I have a program that downloads some files from Internet. The file name could be very long (100 chars).
The user may choose to save these these files in a folder that has a very long name (200 chars).
So, the total length of the path is over 260 chars.
I tried to create a function that checks if the path is too long and truncates the filename so the whole path will be exactly 260 chars. But functions in TPath class fails to work if the path is over 260 chars. More exactly GetDirectoryName raises a specific error when the path is over 260 chars, so I cannot use it to split the folder from file name.
A major design flaw in Delphi?
I think that TPath raising an error when working on long file names is a big flaw. Simply using GetDirectoryName to READ (not to write) will simply crash your program. TPath should allow processing long paths. MAYBE it should raise the error ONLY when you try to WRITE files with long path. But not even then. NTFS accepts long paths. So, why Delphi should force you to stick to 260? Some programs can handle longs paths. For example, I use Total Commander (never Explorer) so I am not affected by the long file name issue.
Any idea on how to treat this case?
Note: The download process is automated so I won't stop to ask the user to enter a new file name for each file that fails to be under 260 chars. I want to handle this silently.
Personally, my opinion is that TPath is simply wrong here. To assert that Windows paths cannot be greater than 260 characters is simply denying reality. What's more, to deny you the ability to perform text processing on paths is really quite inexplicable. In my opinion then, TPath should be avoided.
Which leads you back to the good old days. You can call ExtractFileDir from SysUtils. It works as well as it ever did.
I have an application and posted to Cydia recently. It has been cracked by someone else and posted it in torrent sites. I have a binary checksum verification mechanism inside and they were able to create a new checksum file based on the changes they have made to the binary. They have edited two functions and decompiled it and posted it to torrents.
I saw that it's possible to see the actual implementation of functions and classes. But in order to edit the functions they have to find the address of that function and edit it via HEX EDITOR. I don’t want to make it "unhackable", but I really want to find out how they hack.
How can I edit a function in an iOS binary and re-compile it? For example I have a following method in one of my classes.
- (id) getSomething {
return #"Something";
}
I want to edit the return value of this function. Is that possible?
Usually, you don't "re-compile" it. Just feed the file to IDA, look for strings, function calls or whatever you are looking for and then use a hex editor or similar to edit the file on assembly level. In most cases it's enough to simply change a conditional jump into an unconditional jump or a nop (no operation). If you want to change return values, you have to put a little more effort into it, but in my experience you either edit the char sequence right inside the binary file, if it's specified as a constant or initial value - or you just write a completely new function and "copy" the assembler code of it into the original file. You just have to make sure your new function does not take more space than the original - or everything's getting a lot more complex.
I hope that's what you were asking for, otherwise just tell us which app you are talking about and we can look deeper into it :)