CLI 2.0 file permissions recommendations

Options
paulpharr
paulpharr
Community Member
in CLI

in looking at our server logs after switching some access to go through CLI 2.0, I see the following error output on most calls:

couldn't start daemon: open /run/user/0/op-daemon.pid: permission denied

everything is running on AWS linux 2

does not affect the functionality - all calls are working afaict

im sure this is related to some installation/execution permissions differences yet to be investigated, but it's a good opportunity to ask if you have comments on permissions best practices for server installs of CLI 2? I believe we used the same permissions as CLI 1 and we have not seen this earlier.

thanks

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided

Comments

  • simon_1P
    simon_1P
    Options

    Hi @paulpharr, thanks for reaching out!

    The most common use case for the daemon is caching. Are you passing --cache to your commands?

    does not affect the functionality - all calls are working afaict

    When the daemon cannot be reached for caching purposes, the CLI continues without using the cache (re-fetching the items from 1Password servers).

    im sure this is related to some installation/execution permissions differences yet to be investigated

    There are some installation differences between 1Password CLI version 1 and 2. Most notably, version 2 is/should be owned by the onepassword-cli group. You can validate this using ls -l $(which op).

    I realize it has been a month since you reached out about this. Have you been able to investigate and possibly remediate your installation? I'm curious if you have any findings, as I think we should improve the error message we're providing in case there's installation changes you should be making to remediate this.

    Cheers,
    Simon
    Developer, Developer Products

  • samarthj
    samarthj
    Community Member
    Options

    I am having the same issue on macos. All versions of linux I am running on are just fine.

    Even without using cache the error is ever present. I literally get it on op help. I have tried to remove it from the system and reinstall, no dice.

    You say that it should be owned by the onepassword-cli group, which it is not. Does that still hold for macos? And if it does, that is something the installer should be doing right?

    Regardless I tried it and it doesn't work. Incidentally it is also missing the kernel secure permission, which doesn't help either.

  • Horia.Culea_1P
    Horia.Culea_1P
    Options

    Hey all,

    I will be filing an internal issue for investigating this error.

    You say that it should be owned by the onepassword-cli group, which it is not.

    This only applies on Linux where, indeed, the installer takes care of this aspect.

  • andi.t_1P
    andi.t_1P
    edited August 2022
    Options

    Hi @paulpharr, @samarthj. Coming back at investigating this issue, it seems like op tries to open/create a path you do not have access to, thinking op-daemon.pid will be found there (e.g /run/user/0/op-daemon.pid). It does that in order to start-up the daemon process that is generally responsible for caching, but also for expired session file cleanup, which is why it needs to be running on every command invocation, hence, the ever present error message.

    Now, there are 2 places where op-daemon.pid could be located. Most often it will be located in the temp folder ($TMPDIR), but for you this seems not to be the case. The 2nd place where it could be located is the path specified through $XDG_RUNTIME_DIR. This latter case happens if and only if $XDG_RUNTIME_DIR env var is set at the time of command execution.

    I would suggest the following line of thought:

    Echo your $TMPDIR. Is it the same with the path output in the error? If yes, then to overcome this issue you would need to set the $TMPDIR to a path you know for sure that you have access to on your machine. If no (this is where I'd place my bet), most likely somewhere along the way $XDG_RUNTIME_DIR gets modified to a path you do not have access to, so you need to remove that side-effect from your environment.

    (It is also possible that your $TMPDIR gets altered somewhere in the process, but this is extremely unlikely imo.)

    Would love to hear back from you regarding this issue and what these instructions uncovered for your use cases.

    Until then all the best,
    Andi

This discussion has been closed.