Linux CLI only seems to work as user 'root'.
I'm using the latest CLI software (version 0.2) under linux, and it only seems to work as root.
As user root, I can do the following, where USER@DOMAIN.COM is my user ID and SECRET-KEY is my secret key ...
# cd $HOME
# unset OP_SESSION_my
# /bin/rm -rf .op
# eval $(/usr/local/bin/op signin my.1password.com USER@DOMAIN.COM SECRET-KEY)
Please enter your password for user USER@DOMAIN.COM at my.1password.com:
[[ I properly enter my password ]]
# /usr/local/bin/op list items
... JSON list of my items correctly prints out ...
However, if I run the exact, same series of commands as a non-root user, I get the following result ...
[LOG] 2017/12/19 04:46:11 (ERROR) You are not currently signed in. Please run
op signin --helpfor instructions
As a non-root user, even prefixing the /usr/local/bin/op commands with sudo doesn't fix the problem. I still get the same error message.
Any suggestions?
Thank you.
1Password Version: Not Provided
Extension Version: CLI 0.2
OS Version: Linux 4.10.0-42-generic
Sync Type: Not Provided
Comments
-
I'm using the latest CLI software (version 0.2) under linux, and it only seems to work as root.
As user root, I can do the following, where USER@DOMAIN.COM is my user ID and SECRET-KEY is my secret key ...# cd $HOME
# unset OP_SESSION_my
# /bin/rm -rf .op
# eval $(/usr/local/bin/op signin my.1password.com USER@DOMAIN.COM SECRET-KEY)
Please enter your password for user USER@DOMAIN.COM at my.1password.com:
[[ I properly enter my password ]]
# /usr/local/bin/op list items
... JSON list of my items correctly prints out ...However, if I run the exact, same series of commands as a non-root user, I get the following result for the /usr/local/bin/op list items command ...
[LOG] 2017/12/19 04:46:11 (ERROR) You are not currently signed in. Please run
op signin --helpfor instructionsAny suggestions?
Thank you very much.
1Password Version: Not Provided
Extension Version: CLI 0.2
OS Version: Linux 4.10.0-42-generic
Sync Type: Not Provided0 -
PS: Even if I prefix the /usr/local/bin/op commands with sudo for the non-root user, I get the same error message.
0 -
Hrmm.. that’s odd. The majority of the tool has been built from Linux, using a regular user account.
Can you check a few things for us? Can you look to see if ~/.op was created for your regular user? And could you also make sure that they have write access to $TMPDIR?
Let’s start with those and work from there.
Rick
0 -
~/.op is indeed owned by the normal user. However, your TMPDIR suggestion is helpful. For me, that environment variable is set to /opt/tmp which has 777 permissions and is owned by root:root ... just like /tmp. I noticed that under /opt/tmp, the following directory exists: com.agilebits.op, and because I first tried running op as root, that directory was created with root:root ownership. And it has 755 permissions. This prevents the normal user from writing to it.
I can only view my system now and not run any commands on it, so I can't delete that directory or change its permissions and ownership at the moment ... I'll be able to perform that test in a few hours. I will do so and report back here. If it turns out that $TMPDIR/com.agilebits.op being owned by root:root is indeed the problem, then this points to the fact that more than one user on any given machine cannot run op. If that's indeed the case, then I'd like to request the following functionality in op ...
Either (1) create a directory called $TMPDIR/com.agilebits.op.uid, where uid is the user ID of the user that is running op (either the numeric user id or the user name),
or (2) make sure the $TMPDIR/com.agilebits.op directory is always created with 777 permissions, and that any files that op needs to write to in that directory have group-write and other-write permissions, in addition to owner-write,
or (3), create com.agilebits.op within each op user's ~/.op directory, instead of under $TMPDIR.I'll write back in a few hours with my findings.
0 -
@HippoMan : i've asked @cohix and @jpgoldberg to take a look at this as they're more familiar with the expectations of a linux user. I'm a Mac user and I'm pretty sure on OS X, $TMPDIR is always set to somewhere unique to the user.
Rick
0 -
Thank you for this.
In Linux, there is no requirement that TMPDIR be user-specfic. It often is set to point to /tmp.
Given that there is no requirement for TMPDIR being user-specfic under Linux, I recommend that op should not make use of TMPDIR to hold user-specfic info.
And since op already makes use of the user-specfic ~/.op directory, I recommend that the user-specfic items it currently accesses under TMPDIR should now start living under ~/.op. This will work equally well under Linux and MacOS.
0 -
I have tested this, and op indeed works under Linux if I temporarily set TMPDIR to ~/.op.
This demonstrates that op should work fine if it puts its user-specific info under ~/.op instead of under TMPDIR. I will be able to test this on a Mac tomorrow, but I'm confident that it will work equally well.
Perhaps you could pass this info on to @cohix and @jpgoldberg and to the op development team.
Thank you again for all your help!
0 -
PS: many standard Linux programs now use TMPDIR instead of specifically hard-coding /tmp, and they expect the files in TMPDIR to be treated the same way that files are treated under /tmp ... i.e., when the system gets rebooted, the files in /tmp are expected to be deleted. If TMPDIR pointed to arbitrary, user-specific locations, there is no guarantee that the files under TMPDIR would be deleted at reboot, since the OS would have no idea what the setting of TMPDIR is for each and every program and user.
Users sometimes play with TMPDIR and make it point to non-standard locations, but in doing so, they might break some of the conventions of the standard Linux programs that make use of TMPDIR. I make TMPDIR point to /opt/tmp on my Linux box, because my /opt partition is much larger than the space allocated for /tmp. But also, I have modified my system startup code to delete everything in /opt/tmp at boot time, and therefore, it's the moral equivalent of /tmp.
Also, keep in mind that TMPDIR is a Unix/posix construct that MacOS borrowed. If MacOS uses TMPDIR differently from how Unix/posix uses it, then MacOS is the entity which has deviated from the original standards, and this complicates the porting of Unix/posix programs to MacOS. In any case, since MacOS and Linux treat TMPDIR differently, the os program should not rely on TMPDIR.
0 -
PPS: another possibility is to define an optional attribute in ~/.op/config called tmpdir or something similar. If that attribute exists, op would use it instead of the value of the TMPDIR environment variable. Users could set it to point to a user-specific area. Of course, if this method is utilized, then the op program should never automatically set or delete the value of that tmpdir attribute, if it already exists.
0 -
*** redundant comment deleted ***
0 -
Thanks @HippoMan,
I've filed an issue in our tracker for this problem. It's issue number 322. We'll get this fixed up.
Thanks for reporting it.
Rick
0 -
Thank you! I'm looking forward to being able to use a future version of op in multiple accounts. In the mean time, I'll manage with the current version.
0 -
Sounds good.
Rick
0 -
I probably should have posted an update here a month ago, when version 0.3 was released. This is now fixed.
The directory that op creates in $TMPDIR now includes your Unix uid in the name. This isn't needed on those systems in which $TMPDIR is already user specific, but it is needed on some Linux-es. I also got to make a "sticky bit" pun in some internal comment on the issue, but the young folk around here didn't pick up on it. (Or just ignored it, as would also be a sensible response.)
As always, the session information stored in those is encrypted.
So please give it a try @HippoMan, and let us know how this goes.
0
