Bug 214665
Summary: | security bug:using "truncate" bypass disk quotas limit | ||
---|---|---|---|
Product: | File System | Reporter: | leveryd (1157599735) |
Component: | ext4 | Assignee: | fs_ext4 (fs_ext4) |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | djwong, lczerner, tytso |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 3.10.0-1160.36.2.el7.x86_64 | Subsystem: | |
Regression: | No | Bisected commit-id: |
Description
leveryd
2021-10-09 10:23:45 UTC
This is not a bug, but rather things working as expected. This is because truncate does not actually allocate any disk blocks. It merely sets the i_size of the inode to be the specified quantity. If i_size is less than where blocks currently are allocated and assigned to the inode at those logical offsets, then those blocks will be deallocated. But truncate never allocates any additional data blocks. Try running "du id", and see how much disk space the file takes. Or try using "ls -s", which will show the disk space used by the file --- which is different from the size of the file. If this puzzles you, look up the definition of "sparse file". i know `truncate` file does not task up disk space, but i still think it has some "design" problem about security. * why i still think it has some problem? because developer will trust "quota limit" very likely, so they will not check the file is "truncate file" or not before they do some operation on file. for example(assume a scenario): developer limit every ftp user's disk space by using "disk quotas", and there is a crontab job which will backup ftp user's files every day. if this crontab job does not check "truncate file" exist or not and then backup using "tar" or "zip" compress command, then when a malicious user create a file using `truncate -s 100G id`, after compress this special "truncate file`, the machine disk space will be consumed more than 100G actually. Quotas help to control the amount of space and number of inodes used. If the sparse file (created by truncate, or seek/write, or any other method available) does not actually consume the fs space, then it simply can't be accounted for by quota. So as Ted already said it is working as expected. Back to your scenario. Quota has nothing to say about how the files are manipulated so if the program copying/decompressing or otherwise manipulating the sparse file decides to actually write the zeros and thus allocate the space, so be it. That's hardly a bug in quota or file system itself. If your expectation is that while manipulating the sparse file, the file will remain sparse, you should make sure that the tools you're using will actually do what you want. Note that tar does have --sparse options which, if I understand your example correctly, should work as you expect. Some basic information about sparse can be found here files https://en.wikipedia.org/wiki/Sparse_file As Lukas said, "truncate" is not the only way to create sparse files. And there are many Unix / Linux programs that depend on the ability to create sparse files, since Unix support of sparse files goes back at roughly 50 years (half a century). The fact that clueless users / sysadmins might not understand basic Unix/Linux behavior is not a bug in Linux. There are plenty of other ways that an experienced sysadmin might shoot themselves in the foot.... Correction to #4: There are plenty of other ways that an *inexperienced* sysadmin might shoot themselves in the foot.... (In reply to Theodore Tso from comment #5) > Correction to #4: > > There are plenty of other ways that an *inexperienced* sysadmin might shoot > themselves in the foot.... I disagree, there are plenty of ways experienced sysadmins and kernel maintainers such as myself shoot themselves in the foot. ;) |