On 3. 3. 26 19:52, Daniel Sahlberg wrote:
Den tis 3 mars 2026 kl 18:53 skrev Sean Palmer <[email protected]>:
Failure as early as possible and with as little I/O
performed as possible would definitely be my preference,
but even writing and then bailing with deletion would be
acceptable for us, I expect.
I agree that just how widely such a feature would be used
is hard to say. If nobody has requested it yet in the 25
years that Subversion has been available, that probably
tells us something. But I see signs that the industry is
ramping up security compliance efforts, so perhaps more
attention will be paid in the future to this class of
problem. See e.g. CWE-400.
https://cwe.mitre.org/data/definitions/400.html
--sbp
CWE-400 would certainly apply to the mod_dav_svn and svnserve servers
where we (can) have anonymous users accessing the server remotely. I'm
not sure if HTTPD will protect us here (it won't help us for svnserve
but inetd might).
I'm not so sure if we SHOULD offer protection to that kind to the
command line client. We can't reasonably set a default limit in the
client (or we'd get loads of angry users having WCs larger than that
limit). We could of course add a command line parameter, but most
users wouldn't even use it.
To me this feels like a solution on the wrong abstraction level. If
I'm managing a shared system, I'd limit resources on the OS level
(using some kind of disk quota) to also protect from someone doing dd
if=/dev/null of=/home/folder/trash.
That would be /dev/zero instead of /dev/null, but yes.
There's another catch. Because the checkout/update protocol is streamy,
the client can't make an estimate of the required on-disk size without
reading at least metadata for the whole tree from the server. That's the
equivalent of 'svn info --recursive ${URL}'.
And even then, the client could mispredict the required size quite
badly, because disk usage depends on more than just the sizes of the
files we write. For example, it also depends on the filesystem block
size; all files on disk allocate fixed-sized blocks, so they use more
space than their size in bytes. And how do we predict the size of the
sqlite database?
I'll not even try to think too much about filesystem-level deduplication
and comporession, or compressed and in-database pristines.
All that non-trivial work to get a bad prediction ... that is trivially
avoided by setting per-user and even per-directory quotas.
-- Brane
