Permissions and isolation | SFTP: transfers and batch operations

Concept and mechanism

Successful authentication does not grant unrestricted file access. The account needs permission to traverse directories and perform the intended operation. Reading the final file does not resolve missing search permission on an ancestor directory. The subsystem can add other restrictions: sftp-server in read-only mode refuses changes even when filesystem permissions would allow writing. In OpenSSH, ChrootDirectory requires path components owned by root and not writable by group or others. Giving the chroot root to the partner can prevent session startup. Separate that protected root from a child directory where the account has only the writing it needs.

Guided application

StrictModes does not remove mandatory chroot checks. ForceCommand internal-sftp also does not itself disable TCP, agent, or other forwarding channels; review those capabilities separately. For new files, umask clears bits from the requested mode. In the example with 0666 and mask 0027, the result is 0640, assuming no ACL and no later preservation or chmod changes. Do not generalize this outcome to every tool. For a denied upload, identify policy, path, owner, and effective permissions before proposing changes. Avoid global permissions as an automatic response: they can violate isolation and conceal the actual observed failure cause.

IN PRACTICE

Protected chroot root; delivery child directory with authorized writing.

Common pitfalls

Authentication as authorization; StrictModes as bypass; forced command as every channel; umask as direct final mode.

Related topics: Transport and server trust · Batch and observable failures · File publication and resumption

Take this idea with you

Assess controls together and change only the required scope.

Create account

Reference: OpenSSH daemon configuration · DR SFTP 2026-09; selected OpenSSH client, server and extension behavior