SQLite在低并发网站中的安全配置与文件权限

SQLite数据库文件本质上就是一个普通的磁盘文件，它的安全性几乎完全取决于操作系统层面的文件权限和部署目录的访问控制。很多人部署完应用后，数据库文件能被任意用户读取甚至下载，问题就出在文件所有者和权限位没有正确设置。

先看一个最常见的错误场景：你用root用户运行了初始化脚本，生成的SQLite数据库文件所有者变成了root，权限是644。之后Web服务器以www-data用户运行，虽然能读写，但其他普通系统用户也能直接cat这个文件。如果数据库文件放在了Web可访问的目录下，比如网站根目录的/data文件夹里，攻击者直接通过URL请求就能把整个数据库下载到本地，所有用户密码哈希、私信内容、订单信息瞬间暴露。

这是第一条铁律。SQLite数据库文件绝不应该放在会被Web服务器直接对外提供静态文件服务的目录下。正确的做法是把数据库文件放在Web根目录的上一级或者系统专门的数据目录中。例如你的网站根目录是/var/www/html，那么数据库文件应该放在/var/www/data/或者/opt/myapp/data/这类位置。应用程序代码通过绝对路径去引用这个文件，而外部请求无论怎么构造URL都无法触及。

如果因为某些原因必须放在Web根目录内，那至少要配合Web服务器的访问控制规则来屏蔽对.db文件的直接请求。Nginx下可以这样配置：

location ~* \.db$ {
    deny all;
    return 403;
}

Apache下在.htaccess或者虚拟主机配置中加入：

<FilesMatch "\.db$">
    Require all denied
</FilesMatch>

但即便做了Web层面的屏蔽，仍然不建议把数据库放在Web根目录下。配置失误、Web服务器漏洞、或者临时替换配置文件都可能导致屏蔽失效，风险完全没必要承担。

Linux系统下，SQLite数据库文件应该只对运行应用程序的那个用户开放读写权限。假设你的Web应用以www-data用户运行，那么正确设置是：

chown www-data:www-data /var/www/data/mydb.sqlite
chmod 600 /var/www/data/mydb.sqlite

权限600意味着只有文件所有者可以读写，同组用户和其他用户完全没有权限。很多人习惯设成644或者755，这会让系统上其他用户都能读取数据库内容。在一个共享主机环境或者有多个用户登录的服务器上，这就是严重的信息泄露风险。

同时要注意数据库文件所在目录的权限。如果目录权限是755且所有者是root，www-data用户虽然能进入目录并读写自己的文件，但如果目录权限是777，其他用户就能删除或替换数据库文件。目录权限应该设为700或750，确保只有必要的用户能进入：

chown www-data:www-data /var/www/data/
chmod 700 /var/www/data/

开启WAL模式后，SQLite会生成两个额外的文件：-wal文件和-shm文件。这两个文件与主数据库文件在同一目录下，需要同样的权限保护。如果在应用运行过程中动态创建了这些文件，它们的权限继承自创建进程的umask设置。很多系统默认umask是022，这意味着新文件权限会是644或755，这又回到了权限过宽的问题。

解决方法是在应用启动时显式设置umask，或者在创建数据库连接后立即修正相关文件的权限。在Python应用中：

import os
os.umask(0o077)  # 在创建数据库连接之前设置

PHP应用中可以在php-fpm的池配置里设置：

umask = 0077

这样应用进程创建的任何文件默认权限都是600，WAL文件和临时文件都不会有权限泄露的问题。

很多人认为只要用了SQLite加密扩展就万事大吉，这是一个误解。SQLite官方提供的加密扩展是商业授权的，开源生态中常用的替代方案是SQLCipher。加密确实能在文件被窃取后提供保护，但它解决不了运行时通过应用漏洞读取数据的问题，也解决不了权限配置错误导致文件被替换的隐患。

对于低并发网站来说，加密带来的性能开销通常可以接受，但增加了部署复杂度。如果你的服务器本身已经做了严格的访问控制和文件权限管理，加密的边际收益有限。真正需要加密的场景是：数据库文件需要通过网络传输、存储在不可信的云存储上、或者需要满足合规性要求。判断标准很简单：如果有人拿到了你的.db文件，他能不能直接打开看到明文数据？如果答案是能，而你的数据又涉及用户隐私，那就应该上加密。

SQLite本身权限模型简单，没有用户账户体系，但这不意味着SQL注入的危害就小。通过SQL注入，攻击者可以执行ATTACH DATABASE命令，将另一个数据库文件附加到当前连接中，然后读写那个文件。如果应用进程对文件系统有写权限，攻击者就能创建新的数据库文件或者覆盖重要文件。

防御措施除了参数化查询之外，还可以在连接数据库后执行：

PRAGMA database_list;

检查是否有非预期的附加数据库。更彻底的做法是编译SQLite时禁用ATTACH功能，但这需要自己编译SQLite源码，在编译选项中加入：

-DSQLITE_OMIT_ATTACH

对于绝大多数低并发网站，使用参数化查询配合最小权限原则已经足够。关键是把数据库进程的文件系统权限限制在它必须访问的那几个目录和文件上，即使发生了SQL注入，攻击者也无法通过ATTACH去操作系统其他位置的敏感文件。

很多网站的自动备份脚本用root权限运行，把数据库文件复制到备份目录后，备份文件的权限变成了root所有、644权限。如果备份目录又在Web可访问范围内，问题比原始数据库文件暴露更严重，因为备份文件往往包含更完整的历史数据。

备份脚本应该以应用用户身份运行，或者备份后显式修正权限：

cp /var/www/data/mydb.sqlite /backup/mydb_$(date +%Y%m%d).sqlite
chown www-data:www-data /backup/mydb_*.sqlite
chmod 600 /backup/mydb_*.sqlite

另外，SQLite的.backup命令比直接复制文件更安全，它能在备份过程中保持数据库一致性，不会出现复制到一半数据库被写入的情况。在sqlite3命令行工具中：

sqlite3 /var/www/data/mydb.sqlite ".backup /backup/mydb_backup.sqlite"

备份文件同样要遵循最小权限原则，并且备份目录绝不要放在Web根目录下。

应用程序在运行SQLite查询时如果开启了错误日志，SQL执行失败时可能把完整的SQL语句连同参数值一起写入日志文件。这些日志文件如果权限设置不当或者被Web访问到，敏感数据就间接泄露了。检查你的应用框架配置，确保生产环境下关闭SQL日志或者将日志级别设为ERROR以上，同时日志文件目录的权限要和数据库文件一样严格管控。

PHP的PDO在异常模式下会把连接信息输出到错误信息中，虽然不包含数据库文件路径，但堆栈跟踪可能暴露代码结构。生产环境务必关闭display_errors，log_errors的日志文件也要保护好。

在Docker环境中部署SQLite应用时，数据库文件通常通过卷挂载来持久化。挂载点的权限问题经常被忽略。如果容器内应用以非root用户运行，而宿主机上挂载目录的所有者是root，容器启动后应用无法写入数据库文件。反过来，如果为了方便直接给挂载目录777权限，宿主机上其他容器或进程就能读取这个数据库。

正确做法是在Dockerfile中明确创建应用用户，确保其UID与宿主机上挂载目录的所有者一致，或者在容器启动脚本中动态修正权限。挂载目录权限设为700，数据库文件权限600，和物理机部署的标准一致。

部署完成后，权限配置可能会因为系统更新、人为操作失误、或者应用自身行为而改变。建议在监控脚本中加入权限检查，定期验证数据库文件和目录的权限是否符合预期：

#!/bin/bash
DB_PATH="/var/www/data/mydb.sqlite"
DB_DIR="/var/www/data"

# 检查文件权限是否为600
FILE_PERM=$(stat -c "%a" "$DB_PATH")
if [ "$FILE_PERM" != "600" ]; then
    echo "警告：数据库文件权限异常，当前为$FILE_PERM"
fi

# 检查目录权限是否为700
DIR_PERM=$(stat -c "%a" "$DB_DIR")
if [ "$DIR_PERM" != "700" ]; then
    echo "警告：数据库目录权限异常，当前为$DIR_PERM"
fi

把这个脚本加入crontab每小时执行一次，或者集成到监控系统中，能在权限意外变更时第一时间收到告警。

SQLite在低并发网站中的安全性，核心就是把数据库文件当作一个包含所有敏感数据的普通文件来保护。文件放在Web不可达的位置、权限设为仅应用用户可读写、目录权限收紧、WAL文件不遗漏、备份文件不放松、日志输出要谨慎。这些措施单看每一条都不复杂，但组合起来就能构建起一个可靠的安全基线。SQLite的简单性恰恰是它的安全优势，因为没有复杂的网络端口和用户认证体系，攻击面天然就小，只要守好文件系统这道门，安全性就能达到很高的水平。