Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Locking does not work. #4

Open
stefbon opened this issue Dec 5, 2016 · 2 comments
Open

Locking does not work. #4

stefbon opened this issue Dec 5, 2016 · 2 comments

Comments

@stefbon
Copy link

stefbon commented Dec 5, 2016

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
Copy link
Author

stefbon commented Dec 30, 2016

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

@27o
Copy link

27o commented Dec 17, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants