Can we change where op looks for .op folder?

kasey_junk

Previous versions followed symlinks but recent versions no longer do. This means that the .op folder must be in the home directory.

---

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

Ben

Hi @kasey_junk

I can confirm that recent versions cannot follow symlinks:

[LOG] 2020/04/15 14:16:44 (ERROR) Can't continue. We can't safely access "/Users/bdw/.op" because it's a symbolic link. Replace the linked file with the original file and try again.

I'm going to check with our development team to see if there is any way around this or another solution. Thanks!

Ben

Ben

I just spoke with development and it seems op should be obeying the XDG_CONFIG_HOME environment variable. Could you please try setting that to the path where you'd like op to look?

Thanks!

Ben

kasey_junk

That does not appear to work. I set that environment variable and specified a signin for an account stored in a config in the directory I set in the environment variable. It did not work.

felix_1p

Hey @kasey_junk, can you share how exactly you set the environment variable? Just to make sure that that worked correctly. At the same time I will double check that our code is correct.

jgoguen

It is respecting XDG_CONFIG_HOME, but not quite correctly. There's two problems I observed:

1. Without XDG_CONFIG_HOME set, op is using the home directory. The standard dictates that if XDG_CONFIG_HOME is not set, ${HOME}/.config should be used as the default value of XDG_CONFIG_HOME. It says "SHOULD", but in a standard this is interpreted as "there may be a legitimate reason to ignore this, but be very careful assessing that and don't ignore this unless you have a really good reason". Or, "SHOULD" is basically "there's the odd case where this would be infeasible but it's almost a MUST" (because everyone else will assume you're doing it or clearly documenting why you aren't).
2. With XDG_CONFIG_HOME set, op is expecting to use ${XDG_CONFIG_HOME}/.op/. This is technically allowed, I'm not aware of anything that dictates how you name your config directory, but the de facto standard is to not use a dot directory (it should use ${XDG_CONFIG_HOME}/op instead) because XDG_CONFIG_HOME is normally already hidden in the user's home directory or (like XDG_CONFIG_DIRS) is outside the user's home directory.

Based on this, ~/.op should not be used at all, ${XDG_CONFIG_HOME} must be used if set or assumed to be ${HOME}/.config if not set, and ${XDG_CONFIG_HOME}/op should be the preferred config directory for op. What happens if someone has configuration at ~/.op or ${XDG_CONFIG_HOME}/.op isn't defined, but either migrating to ${XDG_CONFIG_HOME}/op iff that doesn't already exist or alerting the user they're using a legacy config location seem fine.

If I could have an "op wishlist" for this, it would be:

• 0.10.1: Print a discrete warning with every op invocation that ~/.op and ${XDG_CONFIG_HOME}/.op (iff they exist, else print nothing) are deprecated and will be moving to ${XDG_CONFIG_HOME}/op in 0.11.0.
• Somewhere before 0.11.0: Print a big warning, optionally offer to migrate existing settings to the new location.
• 0.11.0: Only ${XDG_CONFIG_HOME}/op is used.

felix_1p

@jgoguen : Thank you for this! You are right, we are not doing a good job with how we handle XDG_CONFIG_HOME (or rather its default fallback path). I will discuss this with the team.

lhriley_medal

@felix_1p or @Ben has this been addressed in any way? I'm attempting to upgrade to the latest version of op CLI (1.1.1 from 0.9.2) and this is a blocker due to how the tool behaves when the ~/.op directory is actually a symbolic link.

In our case, we use the op CLI inside of a docker developer tools container and mount a volume that contains the op config. We then link the directory within the volume to the expected location. Since the overlay filesystem of the docker container spans multiple filesystems, switching to a hardlink isn't allowed. Storing the op config within the container itself would break our workflow as it would require users to re-register the op CLI every time they reinstantiate the container.

By failing on detection of a symbolic link, you've effectively broken the tool for us. It would be really great to have some kind of option to ignore the symbolic link detection in cases like ours where we have a (very) non-standard home directory setup.

If this has been addressed, can you point to any documentation on the expected behavior, and how to configure the tool to look in different locations for the config?

jgoguen

I don't know how Docker works, could you bind mount the op config directory in the right place? If it gets mounted in the Docker container at /mnt/op you should be able to mkdir /home/${USER}/.op; mount --bind /mnt/op /home/${USER}/.op. I was able to bind mount one directory, then bind mount that to ~/.op, then authenticate and do things.

lhriley_medal

@jgoguen yes, in theory we could mount in the way that you suggest. There is some nuance in how docker mounting / filesystems work, which may not allow for your specific suggestion.

However, that would change how all of the tooling we manage is built just to accommodate how the op CLI tool behavior has changed. The better option, in my opinion, is to make op CLI configuration more flexible rather than more opinionated. This is especially important as the op CLI is distributed as a pre-built binary and not a configurable package.

jgoguen

Yes the right solution is for the op CLI to do the right thing. But AgileBits tends to not disclose whether or not something is going to be done until it shows up in product release notes, so we could see it fixed tomorrow or we could be waiting a long time :/

felix_1p

@lhriley_medal I will bring this up with our security team. The reason for preventing symlinks is to make it more difficult to leak/exfiltrate the Secret Key.

Storing the op config within the container itself would break our workflow as it would require users to re-register the op CLI every time they reinstantiate the container.

Do you mean device registration? That wouldn't be the case if all containers share the same device UUID, which is also stored in the config file (since v1.1 I believe).
Alternatively you can use the OP_DEVICE environment variable to specify the device UUID.

lhriley_medal

@felix_1p Thanks for the response. I definitely understand the need to enforce security, especially in a product like 1password.

I'm not talking specifically about device registration UUID, but that would be part of it. We store the entire .op directory (and many other config files for users) on a docker volume that is mounted into our tools container. We have symlinked in specific folders to the container user home directory, and until the recent upgrade this included the .op folder. This allows us to share specific data between multiple instances of the tool container while retaining separation of configuration that we consider transient.

I was able to get everything working by setting XDG_CONFIG_HOME when the container shell launches, but as this can effect applications globally for the user's various config files, it has the potential to have unexpected / unwanted results.

Really, if I could simply set OP_CONFIG_PATH or something similar, it would avoid all of these problems and just use the actual directory where we store the .op config. I might have missed it, but I don't recall seeing anything like this in the documentation.

felix_1p

@lhriley_medal That sounds like a good idea to me. Our security team independently also suggested something like that. We would probably still apply the same security checks to that folder (type, permissions), but I assume that wouldn't be issue for you.

lhriley_medal

@felix_1p That's good to hear. The permissions and ownership checks are definitely important, and should be enforced on whatever the config path variable points to.

Thanks for helping to move this request forward.

ag_ana

On behalf of Felix, you are welcome @lhriley_medal! And thank you for the discussion so far :)

If you have any other questions, please feel free to reach out anytime.

Have a wonderful day :)

felix_1p

@lhriley_medal : v1.3.0 was released today and introduces the OP_CONFIG_DIR environment variable. I hope this helps :smile:

lhriley_medal

@felix_1p excellent. Thanks for the update. I'll try it out as soon as I can.

ag_ana

Sounds good :+1: :) Let us know how it goes @lhriley_medal.