SQLite Permission Denied Errors Due to Incorrect UID Checks in Temporary File Directory

SQLite Temporary File Creation Fails with Permission Denied Errors

When SQLite attempts to create temporary files in a directory, it performs a series of system calls to ensure the directory is writable. However, in certain scenarios, particularly when the process changes its effective user ID (EUID) after starting, SQLite may encounter "Permission Denied" errors even though preliminary checks suggest the directory is writable. This issue arises because SQLite uses the access syscall, which checks permissions based on the real user ID (RUID) rather than the effective user ID (EUID). The discrepancy between RUID and EUID checks can lead to misleading results, causing SQLite to believe a directory is writable when it is not, resulting in failed file creation attempts.

The problem is exacerbated in environments where processes frequently switch their EUID for security or operational reasons, such as in the case of the forked-daapd service running on OpenWRT. In such cases, SQLite may successfully pass the faccessat check (which uses RUID) but fail when attempting to create a file using openat (which uses EUID). This inconsistency can cause critical operations like database vacuuming or file scanning to fail, leading to errors such as "unable to open database file" in logs.

Real UID vs. Effective UID Mismatch in Access Checks

The root cause of this issue lies in the difference between how the access and openat syscalls handle user permissions. The access syscall, by default, uses the real user ID (RUID) to check file permissions, while the openat syscall uses the effective user ID (EUID). When a process changes its EUID, as in the case of forked-daapd, this discrepancy can lead to incorrect assumptions about file accessibility.

For example, consider a scenario where a process starts as root (RUID = 0) and then changes its EUID to a non-root user (EUID = 190). When SQLite checks the writability of /var/tmp using faccessat, the check succeeds because the RUID is still root. However, when SQLite attempts to create a file in /var/tmp using openat, the operation fails because the EUID no longer has the necessary permissions. This mismatch between RUID and EUID checks is the primary cause of the "Permission Denied" errors.

The issue is further complicated by the fact that the access syscall does not provide a built-in way to check permissions using the EUID. While some systems offer non-standard extensions like eaccess or euidaccess, these functions are not portable and may not be available on all platforms. This limitation makes it challenging to implement a universal solution that works across different environments.

Implementing EUID-Based Permission Checks and Alternative Solutions

To address this issue, SQLite needs to perform permission checks using the effective user ID (EUID) rather than the real user ID (RUID). One approach is to replace the access syscall with eaccess or euidaccess, which are designed to check permissions based on the EUID. However, as noted in the discussion, these functions are non-standard and may not be available on all systems. For example, eaccess is specific to GNU libc and is not part of the POSIX standard.

An alternative solution is to use the faccessat syscall with the AT_EACCESS flag, which instructs the kernel to perform the permission check using the EUID. This approach is more portable and aligns with POSIX standards. However, implementing this solution requires careful handling of edge cases, such as systems that do not support the AT_EACCESS flag or have restrictions on the clone syscall, which is used internally by some implementations of faccessat.

Another potential solution is to modify SQLite’s temporary file directory handling logic to perform an actual file creation test instead of relying on permission checks. This approach involves attempting to create a temporary file in the target directory and checking for success. If the file creation succeeds, the directory is deemed writable; otherwise, SQLite can fall back to an alternative directory or report an error. This method eliminates the need for separate permission checks and ensures that the directory is truly writable under the current EUID.

Below is a detailed comparison of the available solutions:

Step-by-Step Implementation of faccessat with AT_EACCESS

1. Identify the Target Directory: Determine the directory where SQLite intends to create temporary files. This is typically specified by the unixTempFileDir configuration or derived from environment variables like TMPDIR.

2. Modify the Permission Check Logic: Replace the existing access syscall with faccessat and include the AT_EACCESS flag to ensure the check is performed using the EUID. For example:

   int result = faccessat(AT_FDCWD, "/var/tmp", W_OK | X_OK, AT_EACCESS);
   if (result == 0) {
       // Directory is writable
   } else {
       // Directory is not writable
   }
   

3. Handle Edge Cases: Implement fallback logic for systems that do not support AT_EACCESS. This may involve using access as a last resort or falling back to an alternative directory.

4. Test the Implementation: Verify the solution on multiple platforms and under different EUID scenarios to ensure compatibility and reliability.

Step-by-Step Implementation of File Creation Test

1. Generate a Unique Temporary File Name: Create a unique file name in the target directory to avoid conflicts with existing files. For example:

   char temp_file_path[PATH_MAX];
   snprintf(temp_file_path, sizeof(temp_file_path), "%s/etilqs_%lx", "/var/tmp", (unsigned long)getpid());
   

2. Attempt to Create the File: Use openat to create the file with appropriate permissions. For example:

   int fd = openat(AT_FDCWD, temp_file_path, O_RDWR | O_CREAT | O_EXCL, 0600);
   if (fd >= 0) {
       // Directory is writable
       close(fd);
       unlink(temp_file_path);
   } else {
       // Directory is not writable
   }
   

3. Handle Errors Gracefully: If the file creation fails, log the error and fall back to an alternative directory or report the issue to the user.

4. Test the Implementation: Ensure the solution works correctly under various conditions, including different EUID settings and restricted environments.

By implementing one of these solutions, SQLite can avoid the pitfalls of RUID-based permission checks and ensure reliable temporary file creation in environments where EUID changes are common. This approach not only resolves the immediate issue but also enhances the robustness of SQLite’s file handling logic across diverse platforms and configurations.