Least Privilege for Transfer Accounts, in Practice

Least privilege is the easiest security principle to say and one of the hardest to actually apply, because the path of least resistance always runs the other way. It is faster to grant a partner full control of a folder than to work out that they only ever download from it. It is easier to reuse the admin account for a quick scripted transfer than to make a scoped one. Every one of those shortcuts leaves a right lying around that nobody needs — and rights nobody needs are exactly what an attacker, or an honest mistake, eventually uses.

On a transfer server the stakes are concrete. Accounts here belong to outside parties and unattended scripts, writing into and reading out of your filesystem by design. If one of those accounts can do more than its job requires — delete what it should only add, read what it should only drop, administer what it should only use — then the gap between "its job" and "its rights" is your exposure, sitting there waiting.

This article turns least privilege into specific, checkable folder rights for the common transfer roles, with the honest tradeoffs spelled out and commands for both Linux and Windows. It is part of our Permissions series and assumes the directory tree is already in place — least privilege decides what rights the folders in that tree actually grant.

What Least Privilege Means for a Transfer Account

Least privilege means each account gets exactly the rights its job requires and not one right more. The test is not "could they plausibly need this?" — almost anything is plausible — but "does the job they do today actually use this?" If a partner only pulls files, write is not a convenience to leave on; it is a right to remove. If an upload account only drops files, the ability to list and read the folder is not harmless; it is reach to delete.

Most transfer accounts collapse into four honest jobs, and the rest of this article walks through each: read-only distribution (they download from you), write-only drops (they upload to you), the deliberate absence of delete rights (almost nobody should have them by default), and keeping administrative power out of transfer accounts entirely. Get those four right and you have removed the large majority of the excess rights a typical transfer server accumulates.

Read-Only Distribution

The most common transfer role is a partner who only ever downloads: price lists, reports, software builds, documents you publish for them to fetch. Their rights should be read and traverse, nothing else. They cannot upload, cannot alter, cannot delete — they take copies and leave the originals untouched.

    # Linux: outbox the partner reads, you publish into
$ sudo chown fileadmin:partnera /srv/sftp/partnera/out
$ sudo chmod 750                /srv/sftp/partnera/out   # you rwx, partner group r-x
$ sudo chmod 640 /srv/sftp/partnera/out/*               # files: you rw, partner r

    # Windows: read + traverse, inheritable, and nothing else
C:\> icacls D:\ftproot\partnera\out /grant FILESRV\partnera:(OI)(CI)(RX)

Two details make this durable. First, publish files owned by your administration account, not the partner's, so the partner is a reader on someone else's files and cannot inherit ownership tricks. Second, resist the reflex to grant "read/write just in case they need to clean up" — they do not clean up your distribution folder; you do. A read-only channel that is genuinely read-only is one of the few places on a transfer server where you can stop worrying entirely, because a reader cannot damage anything.

Write-Only Drops (and Why That Phrase Needs Care)

The mirror image is a partner who only uploads — a nightly export, a batch of documents, a signed order file. The instinct is a "write-only" folder: they can add a file but not browse, read, or manage what is there. That instinct is right, but the phrase hides a subtlety that matters, and the two platforms honor it differently.

A blind drop has two independent properties: cannot list or read existing contents, and cannot delete or overwrite them. The first is easy everywhere. The second is where POSIX and Windows part company, for reasons the next section explains in full. Here is the drop on each platform:

    # Linux: write + traverse, no read -> partner can add files but not "ls"
$ sudo chown partnera:fileadmin /srv/sftp/partnera/in
$ sudo chmod 730                /srv/sftp/partnera/in   # owner rwx, group -wx, other ---

    # Windows: add-file + add-subfolder + traverse, but NOT read or delete
C:\> icacls D:\ftproot\partnera\in /grant FILESRV\partnera:(WD,AD,X)

On both, the partner can drop a file and cannot list the folder. The difference is deletion. The Windows grant above withholds delete entirely, so it is a true add-only drop: the partner can create a file but can never remove or replace one. The Linux version cannot make that promise from permissions alone — anyone with write on a directory can remove entries in it — so a client who guesses an existing filename could still clobber it. That is not a flaw you fix with a cleverer chmod; it is a property of the model, and the durable answer is to collect uploads immediately. A pickup process that moves each arriving file out of the drop and into an area the partner cannot reach shrinks the window in which anything can be tampered with to seconds.

The Case Against Default Delete Rights

Delete is the most casually granted and least examined right on a file server, usually because it arrives bundled. A Windows "Modify" or "Full Control" grant includes delete; a Unix folder you can write to lets you remove its files. So delete tends to be present by default, not by decision — and default delete is a bad default.

Think about what deletion enables in the wrong hands. A compromised account with delete can destroy data outright — the manual version of what ransomware automates. It can quietly remove the evidence of what it did, hollowing out your logs' filesystem counterparts. It can overwrite a not-yet-collected upload so the version you receive is not the version that was sent. None of these require read access or cleverness; they require only the delete right you left on out of habit. The principle is simple: no account gets delete unless a specific, named workflow needs it, and even then you grant it as narrowly as the platform allows.

Applying that principle means understanding how each platform models deletion, because they differ in a way that changes what is even possible.

On Linux: delete is a property of the directory

This is the fact that surprises everyone: on Unix-family systems, the right to delete or rename a file comes from write permission on the containing directory, not from any permission on the file itself. A partner who can write to a folder can delete every file in it — even files they do not own, cannot read, and did not create. Conversely, removing write on the directory stops deletion, but it also stops creation, so you cannot express "add files but never delete them" with plain bits.

The tool that helps is the sticky bit. Set on a directory (it shows as t in a listing, and you set it with chmod +t or a leading 1 in octal), it restricts deletion and renaming so that only a file's owner — or the directory's owner, or root — may remove it. This is why the world-writable /tmp is safe from users deleting each other's files: it carries the sticky bit. On a shared drop folder it does the same job:

$ sudo chmod 1733 /srv/drops/shared     # sticky + write: add files, delete only your own
$ ls -ld /srv/drops/shared
drwx-wx-wt 2 fileadmin fileadmin 4096 /srv/drops/shared
                    ^-- the trailing t is the sticky bit

The sticky bit limits cross-deletion, but notice it does not stop a partner deleting their own uploads, and within a partner's private inbox they own what they drop. So on Linux the honest position is: use the sticky bit wherever a folder is shared, and rely on fast pickup — moving files out to where the partner has no access — to protect uploads from their own uploader. Permissions reduce the risk; the workflow eliminates it.

On Windows: delete is its own right

Windows models deletion far more precisely, and to its credit. Deleting a file requires either the Delete right on that file, or the Delete Subfolders and Files right on its parent folder. Neither is implied by the ability to create or write data. That means you can grant "create files and write their contents" while withholding delete entirely — the add-only drop from earlier. The one thing to watch is the bundled rights: Modify and Full Control both include Delete, so granting either hands over deletion by the back door. Grant the specific rights you mean instead:

    # Grant create + write, explicitly NOT delete (avoid M and F which include it)
C:\> icacls D:\ftproot\partnera\in /grant FILESRV\partnera:(WD,AD,X)

    # If a folder wrongly grants Modify, replace it with specific rights
C:\> icacls D:\ftproot\partnera\in /remove FILESRV\partnera
C:\> icacls D:\ftproot\partnera\in /grant  FILESRV\partnera:(WD,AD,X)

The lesson to carry across both platforms: delete is a distinct capability, so treat it as one. Decide who needs it deliberately, grant it to as few accounts as possible, and on Windows never smuggle it in through Modify or Full Control when specific rights would do.

Keep Admin Power Out of Transfer Accounts

The last and most important separation is between the accounts that move files and the accounts that administer the server. Administration means changing configuration, creating and deleting users, reading everyone's logs, and starting or stopping the service. Those powers belong to a small number of named human admins, reached over a separate, well-guarded channel — never to a partner login and never to an automation account.

The reason is blast radius, the subject of a whole later article. A partner credential will eventually leak — phished, reused, pasted into the wrong place. When it does, the damage is bounded by what that account can do. If it can only drop files into one inbox, the incident is small. If it can also administer the server because someone reused the admin login for a transfer, the incident is total. The separation is what keeps a leaked transfer credential from becoming a leaked server.

Automation accounts deserve the same discipline. A scheduled job that fetches a file needs a scoped, non-interactive account with rights to exactly the folders it touches and nothing else — not a shared admin login, not a domain administrator, not "the account we use for everything." Give each automated flow its own identity so you can trace it, rotate it, and revoke it without collateral damage. The hygiene of these service accounts is covered in our transfer authentication series, and the way services model these accounts in the first place is in FTP account models. On Windows, per-user authentication lets you keep every partner and every job as its own confined account rather than a shared one; Sysax Multi Server is built around exactly that per-account model, which is what makes the separation practical to maintain instead of aspirational.

The Read-Write Exception

Occasionally an account genuinely needs both read and write in one place — a partner who manages their own outbound folder, or a working area where a job collects a file, transforms it, and re-drops the result. Treat read-write as a deliberate exception, never a default, and keep it as tight as every other role: one scoped folder, delete withheld unless the workflow truly requires it, and no reach whatsoever outside that folder.

The specific danger with read-write areas is that they feel like general-purpose space, so they quietly accumulate both files and rights. This is where privilege creep — the slow accumulation of grants that were each individually reasonable and are collectively far too much — takes hold fastest. Name the exact job the area serves, scope the folder to it, and review it more often than your read-only and write-only accounts. If you cannot name a single job that requires both directions in the same folder, you are probably looking at two roles that were merged for convenience and should be split back apart.

Roles to Rights, at a Glance

The four roles reduce to a compact grant-and-deny table. Copy it as the starting template for any transfer account, and treat any right outside the "grant" column as something you must justify in writing before adding.

A Least-Privilege Review You Can Run

Least privilege is not a one-time setup; rights accrete as workflows change and nobody removes the old ones. Run this short review whenever you add an account and on a schedule for the ones you have:

1. Name the job in one sentence. "Pulls the nightly price list." "Drops signed orders." If you cannot say it plainly, you cannot scope it.
2. List the folders the job actually touches — usually one, occasionally two. Everything else should be unreachable, not merely unused.
3. Match rights to the direction of travel. Download job gets read; upload job gets add-file. Neither gets both without a reason.
4. Remove delete unless a named workflow needs it, and on Windows confirm no Modify or Full Control is quietly carrying it.
5. Confirm it is not an admin. The account must not administer the server, and must not be a shared or interactive login if it is automation.
6. Test as the account. Log in, do the job (it should work), then attempt what the account should not do (it should fail). Configuration screens lie; the login tells the truth.

That last step is the one people skip and the one that catches the real mistakes. A grant that looks right in the ACL editor and a grant that behaves right when you act as the user are not always the same thing, which is why the auditing article leans so hard on effective-permission testing.

Where This Leaves You

Least privilege on a transfer server is mostly the discipline of subtraction: start from the job, grant only what it uses, and treat every extra right — especially delete and especially admin — as a liability to justify rather than a convenience to keep. Read-only channels you can trust completely; write-only drops you make blind and collect fast; delete you withhold by default and grant by exception; and administration you keep entirely separate from the accounts that move files.

The natural next articles are inheritance and umask gotchas, which explain why a correctly designed drop can still produce unreadable or wide-open files, and the blast radius of one stolen credential, which is the payoff for all this restraint. If your least-privilege work is part of a broader server-tightening effort, our hardening transfer servers series puts it in context.

Frequently Asked Questions