Listings leave out the entries naming the listed directory or its
parent, and the names holding a backslash, which no request can
address
Signed-off-by: Nicola Murino <nicola.murino@gmail.com>
A directory rename authorized the whole tree from a walk performed before the
move, so the file_patterns filters and the per-directory rename permissions
decided on the tree as the walk had read it rather than on the one the move
carried.
The walk no longer authorizes the move. A gate decides from the configuration
alone whether anything can tell the entries of the tree apart: a move that
changes which file_patterns filters govern the contents, or a per-directory
permission that restricts renaming defined at or below either tree. When
something can, the object stores check every entry at the moment they move it,
since they rename a directory by recursing into it, and the filesystems that
rename it in a single operation refuse it, because nothing enumerates what that
operation carries. The type of the source is read again immediately before the
move.
Granting rename_files and rename_dirs separately keeps the pre-move walk.
So renaming a folder into or out of a path where a different file_patterns
filter applies is now refused on the local filesystem, SFTP and HTTP, and
checked entry by entry on the object stores; the same holds for a per-directory
permission that restricts renaming inside either tree. Renames the walk used to
refuse fail with the same error as before. IsRenameAtomic is derived from the
same capability instead of matching the filesystem name.
Reported-by: Wade Sparks (@wsparks-vc)
Signed-off-by: Nicola Murino <nicola.murino@gmail.com>
The file pattern filter matches names, and the operations that read an item
evaluate it on the item itself. Three did not agree with that: a copy
evaluated it on the target only, a rename mapped every refusal to a
permission error and so discarded the deny policy configured on the filter,
and symlink creation honored the hide policy alone, letting the default one
through.
They now all evaluate the source and report the configured policy through
GetErrorForDeniedFile, as stat, download and delete already do, so the same
filter gives the same answer whichever operation reaches a name. The target
keeps reporting a permission error: it is a path being written, not an item
being read. isRenamePermitted returns an error and is renamed accordingly;
the recursive walk still reports a permission error, because the entries it
walks are the contents of the directory being renamed and a hidden one among
them must not make that directory look missing.
Signed-off-by: Nicola Murino <nicola.murino@gmail.com>
A virtual folder mapping can now re-root the mount onto a sub-path of
the folder: the mount at the virtual path serves the folder starting
from the configured subpath, which stays invisible in the virtual tree.
The same folder can be mapped multiple times with distinct subpaths;
quota remains a property of the whole folder, so every mapping must use
the same limits.
Supported for local, encrypted, S3, GCS, Azure Blob and SFTP folders.
Fixes#2037
Signed-off-by: Nicola Murino <nicola.murino@gmail.com>
Apply the fixes suggested by the modernize analyzers enabled by
default in gopls v0.23: range over int, errors.AsType, min/max,
slices.Backward/Contains, maps.Copy, strings.Cut/CutPrefix/CutSuffix/
SplitSeq, fmt.Appendf, WaitGroup.Go and b.Loop in tests, new(expr)
instead of to.Ptr, removal of ineffective omitempty tags on nested
struct fields.
Signed-off-by: Nicola Murino <nicola.murino@gmail.com>
Confine all local filesystem access to an os.Root, with path resoultion
enforced by the underlying OS.
Behavior changes an upgrading deployment may notice:
- temp_path is removed and ignored if still configured. Its purpose
was to stage files (atomic uploads, scratch and streaming data)
outside the user's storage and rename them into place, and that is
fundamentally incompatible with the confinement: an os.Root cannot
rename a file in from outside the root, so every staged upload would
degrade to a full copy-then-delete even when temp_path is on the
same filesystem, defeating the very atomicity the option existed to
provide. It was not a great idea before this change either: a
temp_path on a different device already turned the final rename into
a silent full copy. Staged and scratch files (the atomic upload
temporary, the CryptFs download pipe backing file) now live in the
storage root itself, on the same filesystem as the data, so the
final rename stays atomic.
- Cross-folder / cross-root renames are no longer atomic. A rename
spanning the home and a local virtual folder, or two local folders,
falls back to copy-then-delete: slower for large data even on the
same device, and a midway failure can leave a partial tree at the
destination. Symlinks and other non-regular entries inside a moved
directory are skipped, not copied, and the rename still reports
success. File mode bits are not preserved; regular files keep their
modification time, directories do not.
- Absolute symlinks created outside SFTPGo, or by versions predating
this change, are no longer traversable and Readlink rejects them with
permission denied, even when the target is inside the root: os.Root
refuses an absolute link target regardless of where it points.
Symlinks created through SFTPGo are stored relative to the link
directory and keep working.
- Execute-only home directories (e.g. mode 0111) are unusable:
os.OpenRoot requires read permission, so every operation fails with
permission denied until the directory is made readable, where
previously only the listing failed. Since the root open is retried on
demand, fixing the permissions (or creating a missing home
externally) makes the same connection work again without
reconnecting.
Signed-off-by: Nicola Murino <nicola.murino@gmail.com>
The browsable share partial download validated ZIP entries with a raw
byte-prefix check, letting prefix-overlapping siblings (/share vs
/share2) escape the share root. Use a directory-boundary aware check;
harden the event manager twin and add a regression test.
Signed-off-by: Nicola Murino <nicola.murino@gmail.com>
The CryptFs passphrase and the S3 SSE-C key are used directly as
data-at-rest encryption key material, yet they were accepted with no
strength check, so an operator could protect encrypted data with a
trivially guessable secret.
Add common.secret_min_entropy (default 80): when one of these
secrets is submitted in plain text it must pass a minimum-entropy
check before it is encrypted and stored. The check runs on
plain-text input, so secrets that are already stored keep working even
if the threshold is later raised. The estimate is a heuristic used to
reject obviously weak input, not a measure of cryptographic strength:
always supply key material generated by a CSPRNG.
Thanks to Vishal Shukla (@shukla304) for the report.
Signed-off-by: Nicola Murino <nicola.murino@gmail.com>
Moved path sanitization (backslash conversion and path cleaning) to
the SFTP/FTP handlers before VFS routing and permission checks.
Signed-off-by: Nicola Murino <nicola.murino@gmail.com>
the check is performed only on the connection where the transfer is
initiated so it is inexpensive
Fixes#2162
Co-authored-by: Joel Studler <joel.studler@swisscom.com>
Signed-off-by: Nicola Murino <nicola.murino@gmail.com>
rsync was executed as an external command, which means we have no insight
into or control over what it actually does.
From a security perspective, this is far from ideal.
To be clear, there's nothing inherently wrong with rsync itself. However,
if we were to support it properly within SFTPGo, we would need to implement
the low-level protocol internally rather than relying on launching an external
process. This would ensure it works seamlessly with any storage backend,
just as SFTP does, for example.
We recommend using one of the many alternatives that rely on the SFTP
protocol, such as rclone
Signed-off-by: Nicola Murino <nicola.murino@gmail.com>
Nicola Murino