twincitiesguy
commented
2 years ago Unfortunately, when running as a service, you have to pick what user the service runs as. Our service installation script (and the OVA we previously linked to from here) runs the service as root to provide the greatest flexibility for migrations. That design was not intended for a shared end-user use-case.
The use-case you describe doesn't really fall within our objectives for this project, but it does sound like a useful idea. Maybe you could write a service wrapper or script that simplifies running ecs-sync as a CLI command, and your users could use that. I have seen one very similar implementation for an NFS archive use-case.
Closing this as we do not intend to support this feature.
This is a serious security hole. If user A attempts to copy a file directory tree from user B via ecs-sync-ctl (which uses ecs-sync running as a service daemon) for which user A does not have read permissions, the service happily does it granting user A read permissions to user B's directory. Essentially, it is a back door way for user A to read user B's files even when user B has disallowed it,
If user A utilizes ecs-sync in the legacy command-line fashion, the ecs-sync program (which is running as the user) does properly flag a permissions error (i.e. 'no access to this directory'), and exits without making a copy. But if one submits the same XML config file via ecs-sync-ctl to the ecs-sync service daemon, which is running as root, the daemon will go ahead and do the copy. It does copy the ownership correctly, in that the copy is still owned by user B even though user A made the copy. But it also adds o+r (and g+r) permissions to the copy, which allows A to now be able to read the copy, whereas before user A was barred from reading the copy.
For now, we can only allow the legacy CLI access to esc-sync because of this security hole, even though the ecs-sync-ctl "job" paradigm would be much nicer, until we can figure out how to prevent the ecs-sync service from inappropriately granting permissions. Better still, it would be great if ecs-sync, when run as a service, would check the uid/gid of the user submitting the job against the permissions of source/target files, and block inappropriate access.
Too bad. In our benchmarks ecs-sync performs better with a lower resource footprint than other options out there. And we like the job paradigm, particularly for our HPC setting.