sftpserver icon indicating copy to clipboard operation
sftpserver copied to clipboard

Locking does not work.

Open stefbon opened this issue 8 years ago • 2 comments

Hi,

I've found out that locking does not work yet. I got the reply 8:unsupported. See also comment on line 184 in v6.c. Please enable. This requires possibly a table of current locks, and their level.

Stef

stefbon avatar Dec 05 '16 17:12 stefbon

I think the best is to have a seperate process processing the locks: a lock manager. This admin process handles the locking (and possibly other things) on behalv of the different sftpserver's (which are running for different users on different hosts). The sftpserver forwards the lock to this admin process, together with host and domain:

  • type lock (byte range lock, file lock or lease or ....)
  • user@domain
  • for byte range locks offset and size and how (read/write)
  • for flock and leases (todo) how (shared/excl)

The admin process sets the lock. If success, report that. If failed, look for conflicting lock in internal table. If not found check the system's table (/proc/locks). Return SSH_FX_BYTE_RANGE_LOCK_REFUSED with error-specific data describing the blocking lock:

  • who (which user from which host/domain)
  • type lock and how.

Stef

stefbon avatar Dec 30 '16 22:12 stefbon

It is correct to simply return unsupported. supported-block-vector and supported-open-block-vector are set to 1 meaning there is no locking supported.

Remarks for a possible implementation:

You don't want an admin process for this because

  • the locks will vanish if the admin process dies but the client thinks they are still there,
  • there will be stale locks if the client dies,
  • the admin process would have to open every file for this.

The locks itself maps to POSIX record locks. This is fine but there are two problems:

  • there will only be advisory locks as mandatory locks can be optional since Linux 4.5 and are even not supported on most other POSIX compatible OS
  • according to the RFC draft the server must refuse any lock that overlaps with any other lock even on the same connection. This is in contrast to POSIX which automatically replaces the lock for the range with the new one. Even checking for own locks and then trying to lock may not be fully compliant as another thread can change it in the meantime.

27o avatar Dec 17 '17 10:12 27o