CSC 2045: File I/O and Race Conditions

A sequence of characters, often used to represent text or data.

A programming error that occurs when a program accesses data that is no longer valid or has been modified by another part of the program.

A program or system vulnerability that arises from the timing of actions and the potential for conflicting data access.

A programming technique where a program explicitly checks for potential errors and handles them gracefully, preventing program crashes and unexpected behavior.

A set of guidelines designed to promote code quality, performance, and security in C++ development.

std::endl is a manipulator that adds a new line and flushes the output buffer. Flush means to write the buffered data to the destination. However, using std::endl for standard input/output (std::cin/std::cout) is unnecessary and slows down the performance because flushing is already handled automatically. std::endl is also overkill for writing to files, where explicit flushing is rarely needed.

When you use std::endl for standard output, it adds a new line and flushes the output buffer. Flushing means that the buffered data gets written to the destination (usually screen or file). For standard input/output (std::cin/std::cout), flushing is unnecessary because it is already handled automatically. Therefore, using std::endl in this context only adds extra overhead, slowing down your program.

When you open a file using iostreams, you don't need to explicitly close it like in C's stdio library. C++'s destructor handles closing the file when the object goes out of scope. However, it's generally a good practice to close files explicitly to release the resource and prevent resource leaks.

In C++, when you open a file for input or output using iostreams, you should avoid alternating reading and writing operations without explicit positioning or flushing. Doing so can result in undefined behaviour. For instance, don't read from a file and then write to the same file without moving the file pointer using a function such as seekg or seekp.

To avoid resource exhaustion and ensure that data stored in the file buffer is flushed to the file, close files explicitly when you are finished with them. This is especially important for programs that might run for a long time, as remaining open files can prevent other processes from using those files after the program has finished.

When dealing with a file opened for both input and output, it's important to avoid interleaving input and output operations without using positioning functions (seekg or seekp) or flushing the stream. Doing so leads to undefined behaviour, as the file pointer's position gets affected, and the program's actions become unpredictable.

Using std::cout and std::cin for standard input and output in C++ is generally synchronised with printf. This means their actions automatically work together. For example, if you use printf after standard output, the output buffer for std::cout will be flushed before printf executes.

Standard input and output (std::cin/std::cout) are typically synchronized with C's printf library. This implies that when you use std::cout, it is automatically in sync with printf's behaviour.

File names, especially those with special characters or sequences like ".." or "*", can be used to exploit vulnerabilities in programs, allowing attackers to access or modify sensitive information.

A program that uses special characters or sequences in file names to exploit vulnerabilities can cause significant problems, including data loss, system compromise, or denial-of-service attacks.

Restricting the allowed characters in file names can help mitigate vulnerabilities by preventing the use of special characters or sequences that could be exploited.

It is generally unsafe to enable "globbing" (wildcard matching) for file names, as it can greatly increase the computational time and resources needed to process file names, potentially leading to a denial-of-service attack.

Using a separate process with resource limits for handling file name operations can help mitigate the risks associated with "globbing" by preventing resource exhaustion or denial-of-service attacks.

A program should treat file contents as potentially untrusted, even if they are from a trusted user. This is especially true if an untrusted user can modify the file's contents or its directory.

If a program receives instructions from an untrusted user through a file, it must carefully validate those instructions. This includes checking if values are within the expected range and preventing buffer overflows.

A program should not assume that file contents are trustworthy, even if they come from a source believed to be reliable. File contents can be corrupted or altered by external factors or even by malicious users.

A program should not trust file contents that are directly controlled by untrusted users. This means that the program should never blindly execute instructions or process data from a file sourced from an untrusted user.

When a program receives directions from a file, the security of the file's contents must be carefully considered. If the file is controlled by an untrusted user, the program must be extra cautious in handling its contents, validating inputs, and preventing potential security vulnerabilities.

A file stream object used for reading data from a file. It connects your program to an existing file, allowing you to read information from it.

A file stream object used for writing data to a file. It connects your program to a file, allowing you to write information to it.

C++ allows file operations to be performed using the 'fstream' library. This library provides several functions for handling file input and output, making it easy to work with data stored in files.

A function associated with a specific type of object. For example, the 'open()' function is a member function of the 'ifstream' object, allowing you to open a file for reading

The 'open()' function is used to connect a file stream object (like 'ifstream' or 'ofstream') to a specific file. It allows your program to start reading from or writing to the chosen file.

A class that allows you to open and interact with files in C++.

Opening a file is as simple as creating an object. You don't need explicit closing; the destructor handles it when the object goes out of scope.

A file stream that primarily focuses on reading data from files. (Input)

A file stream primarily focused on writing data to files. (Output)

A file stream that can perform both input and output operations.

A potential security issue that arises when the timing of actions and data access can lead to conflicting results. It occurs when a program checks the validity of data at one point in time, but uses that data at a later point when it might be outdated or modified by another process.

A technique used to protect shared resources in multi-user environments. It involves setting the 'sticky bit' on a directory, which prevents users from deleting or renaming files within that directory unless they are the file owner or have special privileges.

A programming technique where a program explicitly checks for potential errors and handles them gracefully, preventing program crashes and unexpected behavior.

A set of guidelines designed to promote code quality, performance, and security in C++ development.

A programming error that occurs when multiple threads or processes access and modify shared resources concurrently, leading to unpredictable and potentially incorrect results.

A type of race condition where a program checks a condition and then performs an action based on that condition, but the condition might change between the check and the action.

Vulnerabilities that exploit TOCTOU errors, leading to unpredictable program behavior, data loss, security breaches, or denial-of-service attacks.

Techniques like atomic operations, locking mechanisms, and careful program design to avoid unnecessary steps. These techniques help prevent TOCTOU errors by ensuring that the system's state remains consistent during critical operations.

Strategies to minimize TOCTOU vulnerabilities, including using locks to control access to shared resources, using atomic operations where suitable, verifying resource states before performing operations, and implementing timeouts to limit the duration of critical operations.