Comments (12)
Sure, I just meant that the path should be properly documented because it's needed for all cases.
BTW, I would prefer to have it in /var/run/parsec instead of /tmp. But, because it would require root privileges for parsec deployment, may be we can use something more parsec specific than we use now. For example /tmp/parsec-service/daemon-socket
from parsec.
This should exist only to test Parsec
installation with systemd
, the communication should only happen inside the container.
from parsec.
An installation script could be used out of this!
from parsec.
I've been looking at this issue and I think we need to clarify its requirements.
For information only:
The small issues I noticed:
- The parsec systemd service definition is missing --config parameter
- The "How to install Parsec on Linux" page is missing a recommendation to un-comment "log_timestamp = false" when Parsec is deployed as a service.
- Hard-coded SOCKET_PATH in parsec service and parsec test clients source code is different from the one defined in the systemd socket definition file. The socket path is documented anywhere.
The main question I have now is what exactly do we want to achieve with this issue?
- Is it about developing, documenting and testing a parsec deployment procedure? Do we know what the typical deployment would be (from a local repo or from crates.io, service on a host or process in a docker container for example, standard service or socket activated one, etc)? Should we cover all?
- What type of systemd service should be tested - standard or socket activated? Do we expect that socket activated services might be used by customers?
- Would manual testing be sufficient or we need a CI one? To be able to use systemd inside a docker container we need to either run the container as privileged (tested on MacOS) or with "--volume /sys/fs/cgroup:/sys/fs/cgroup:ro" parameter (not tested, I need a linux machine for that, doesn't work on MacOS). I don't think the first option is allowed for github CI containers and not sure about the second one as well.
from parsec.
@hug-dev did most (all?) of the work around setting up the "Parsec-as-a-systemd-service" feature, so I can't really comment on most of these things, but I will touch on (3) briefly:
We definitely should document the socket path somewhere and it should be a hardcoded value. As I remember, socket activation was a nice feature to have so that Parsec wouldn't be idling, waiting for a connection, but I'm not sure if we ever resolved the question of "how does a client know where the socket is in that case?" Potentially with an environment variable or with the admin creating a symbolik link from daemon socket to hardcoded socket path?
from parsec.
The question about "where the parsec socket is" exists in all cases, not only in socket activated systemd service.
from parsec.
Not if the socket path is hardcoded and everyone knows exactly where it should be! Then it might, at most, become a problem for the admin if that path is not available.
from parsec.
The reason why a lot of this isn't solidly decided on yet is that we've not had a proper production use case to aim and cater for.
Making the path as Parsec specific as possible is definitely a good aim! I think having root privileges for deployment is sensible to expect, as long as anyone can actually access the socket and write/read from it. It would certainly mitigate some possible threats around other users impersonating Parsec by popping a socket at the right path in the /tmp folder.
from parsec.
FHS even recommends to use /run instead of /var/run (although I saw deployments where / was mounted read-only)
https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s15.html
Anyway, we just need to remember that for development/manual testing we should be able to run parsec without root privileges.
from parsec.
Thanks for your investigation! A few comments on my side:
- the socket path is documented in the Listeners page.
- the installation method described in the book is to install Parsec as an user systemd daemon, without root privilege. Note the
--user
option tosystemctl
commands. - the configuration path is not in the systemd unit file as the daemon is meant to be started from the home directory of the
parsec
user. - thinking about it now, having the socket inside the
parsec
home directory is not a good idea: this folder will probably not be readable by other users. As you mentioned, we should as well probably put the socket in a more idiomatic location. Having a socket in/run
but which is read/writable by other users seems a good idea to mitigate the spoofing threat about it as @ionut-arm said. I think it is expected that some parts of the installation step expect root privileges. But then, if the socket does not exist at that path, Parsec will try to create it, but it won't have the good privilege! This needs to be investigated I guess.
Having at least one installation method that is tested (can be nightly) on the CI would be good I think to make sure that it is possible. Even if that installation method will change in the future.
from parsec.
@joechrisellis looked at it in #218
systemd
is not directly meant to be used inside a Docker container which makes the testing complicated.
This issue could be changed into "testing the Linux permission over the socket with a parsec
user creating the service and multiple client users trying to access it".
from parsec.
Closed in favor of #245
from parsec.
Related Issues (20)
- Yocto parsec build reports warnings related to build paths HOT 1
- Can we have a single "latest" Quickstart release package?
- Parsec fails to compile for arm32 HOT 4
- Vulnerability in SQLite HOT 3
- Investigate using Arm Virtual Hardware in CI
- Suggest using `/dev/tpmrm0` over `/dev/tpm`
- Parsec 1.1 fails to build with meta-security master branch HOT 4
- Parsec Quickstart - Docker: Pull access denied for parallaxsecond/parsec-quickstart, repository does not exist HOT 1
- Update cryptoki version to `0.4.1` HOT 1
- parsec 1.1.0/1.2.0-rc1 fail to build with gcc13 HOT 3
- Generate arm64 quickstart package
- Provide details of built-in providers
- Investigate e2e_tests failure on RasberryPi for PKCS11 backend
- Investigate e2e_tests failure on RasberryPi for TPM backend
- Migrate away from using users crate HOT 1
- Format check errors should only appear in one CI job
- parsec-quickstart container on arm64 HOT 1
- Improve PKCS11 failure mode HOT 1
- e2e_tests/stress.rs: Signature Verification fails sporadically with PsaErrorInvalidArgument
- parsec-cli-tests.sh error: The CSR does not contain the serialNumber field of the Distinguished Name HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from parsec.