#[non_exhaustive]pub struct SecurityConfigFields {Show 16 fields
pub max_file_size: u64,
pub max_total_size: u64,
pub max_compression_ratio: f64,
pub max_solid_compression_ratio: f64,
pub max_file_count: usize,
pub max_path_depth: usize,
pub allowed: AllowedFeatures,
pub preserve_permissions: bool,
pub allowed_extensions: Vec<String>,
pub banned_path_components: Vec<String>,
pub allow_solid_archives: bool,
pub max_solid_block_memory: u64,
pub max_tar_metadata_bytes: u64,
pub max_decoder_memory: u64,
pub parallel_decode: ParallelDecode,
pub zip_consistency: ZipConsistencyPolicy,
}Expand description
The field data of a SecurityConfig, reachable via Deref/DerefMut
regardless of (or gated by) validation state.
This type is not itself part of the sealing boundary — it is a plain data
bag with pub fields, and nothing stops external code from naming it or
cloning one out of a &SecurityConfig. The boundary is
SecurityConfig’s own private fields member: there is no public API
that takes a bare SecurityConfigFields and wraps it back into a
SecurityConfig<Validated>, so an externally-forged or externally-mutated
SecurityConfigFields value can never be smuggled into a Validated
config. It exists purely so SecurityConfig can implement Deref/
DerefMut and keep cfg.max_file_size-style field access working for
every existing caller instead of forcing a getter-method migration.
Fields (Non-exhaustive)§
This struct is marked as non-exhaustive
Struct { .. } syntax; cannot be matched against without a wildcard ..; and struct update syntax will not work.max_file_size: u64Maximum size for a single file in bytes.
max_total_size: u64Maximum total size for all extracted files in bytes.
max_compression_ratio: f64Maximum compression ratio allowed (uncompressed / compressed).
max_solid_compression_ratio: f64Maximum compression ratio of a whole solid 7z block (summed uncompressed size of its files / compressed size of its pack streams).
Solid members share one compressed stream, so no per-file ratio exists;
this limit replaces max_compression_ratio for them. It is not exposed
by the CLI or the Python/Node bindings.
max_file_count: usizeMaximum number of entries that can be extracted.
The extraction API counts files, symlinks and hardlinks, not
directories. list and verify, and the CLI’s extract (which lists
the archive first), count every entry.
max_path_depth: usizeMaximum path depth allowed.
allowed: AllowedFeaturesFeature flags controlling what archive features are allowed.
Use this to enable symlinks, hardlinks, absolute paths, etc.
preserve_permissions: boolPreserve file permissions from archive.
allowed_extensions: Vec<String>List of allowed file extensions (empty = allow all).
Extensions are matched case-insensitively (e.g., "txt" matches both
file.txt and file.TXT). The leading dot must be omitted.
When this list is non-empty, files without a file extension are treated as not allowed and will be skipped during extraction.
banned_path_components: Vec<String>List of banned path components (e.g., “.git”, “.ssh”).
allow_solid_archives: boolAllow extraction from solid 7z archives.
Solid archives compress multiple files together as a single block. While this provides better compression ratios, it has security implications:
- Memory exhaustion: Extracting a single file requires decompressing the entire solid block into memory
- Denial of service: Malicious archives can create large solid blocks that exhaust available memory
Security Recommendation: Only enable for trusted archives.
Default: false (solid archives rejected)
max_solid_block_memory: u64Maximum memory for solid archive extraction (bytes).
7z Solid Archive Memory Model:
Solid compression in 7z stores multiple files in a single compressed block. Extracting ANY file requires decompressing the ENTIRE solid block into memory, which can cause memory exhaustion attacks.
Validation Strategy:
- Pre-validates total uncompressed size of all files in archive
- This is a conservative heuristic (assumes single solid block)
- Reason:
sevenz-rust2v0.20 doesn’t expose solid block boundaries
Security Guarantee:
- Total uncompressed data cannot exceed this limit
- Combined with
max_file_size, prevents unbounded memory growth - Enforced ONLY when
allow_solid_archivesistrue
Note: Only applies when allow_solid_archives is true.
Default: 512 MB (536,870,912 bytes)
Recommendation: Set to 1-2x available RAM for trusted archives only.
max_tar_metadata_bytes: u64Maximum bytes the TAR reader may consume for headers and metadata records in the gap between two consecutive entries.
TAR Metadata Buffering Model:
GNU long-name (L), GNU long-link (K), and PAX extended header
(x/g) records are buffered fully into memory by the underlying
tar crate before any entry reaches the entry validator or quota
tracker — a crafted record can declare a multi-gigabyte length backed
by a tiny compressed stream, exhausting memory with no quota
enforcement (metadata-entry decompression bomb).
Enforcement Strategy:
- A read-budget wrapper meters bytes the
tarcrate reads while searching for the next entry (headers, long-name/long-link/PAX records, GNU sparse extension blocks) and returns an error oncemax_tar_metadata_bytesis exceeded, before any oversized allocation completes - Applies uniformly to
extract,list, andverify - The window this bounds contains no entry data — only metadata — so
it does not interact with
max_file_size/max_total_size. Draining an unread entry before the next header search is a separate concern (seeformats::tar_metadata_limit’s module docs) bounded by synthesized-byte accounting, not by this or any other quota value - Legitimate long-path/xattr metadata records are at most a few kilobytes each, and a GNU tar sparse file with heavy fragmentation can use up to a few thousand 512-byte extension blocks; either or both share this single budget (not “plus” each other), so the default leaves headroom for either shape, not necessarily both at their extremes simultaneously
- The real peak memory this bounds is roughly 5x the configured value
(GNU sparse extension blocks expand into multiple
EntryIorecords per block before the growth is charged against this budget), not an exact multiple — treat it as an order-of-magnitude ceiling, not a tight bound
Default: 4 MiB (4,194,304 bytes)
max_decoder_memory: u64Maximum memory in bytes an xz decoder may use (dictionary and state).
The xz block header declares the LZMA2 dictionary size (up to 4 GiB),
so without a limit a tiny archive can drive resident memory far beyond
what the output quotas allow. Archives that need more fail with
QuotaExceeded { DecoderMemory }. Applies to extract, list and
verify of .tar.xz. Other codecs are bounded by their format
(bzip2 blocks of at most 900 KB; zstd windows above 128 MiB are
rejected) and are not governed by this value. Not exposed through the
CLI or language bindings. Also admits the 7z decoder window; the
lookahead of parallel 7z decoding is budgeted separately by
parallel_decode.
Default: 256 MiB (268,435,456 bytes)
parallel_decode: ParallelDecodeLookahead memory for decoding independent LZMA2 runs of a 7z block on worker threads.
Applies to extract and verify with integrity checking of 7z
archives. It is separate from max_decoder_memory, which keeps
bounding the decoder window. See ParallelDecode.
Default: Bounded at 128 MiB (1 GiB for SecurityConfig::permissive)
zip_consistency: ZipConsistencyPolicyHow ZIP archives with ambiguous structure are handled.
Default: ZipConsistencyPolicy::Enforce, including for
SecurityConfig::permissive. Pre-ZIP64 archives with more than
65535 entries (wrapped end-record count) and archives with orphaned
local headers, or with a central directory signature in a gap before an
entry (left by in-place updaters), are rejected under Enforce.