Avoiding repeated biometric auths in editor subshells

Hey!

It's exciting to hear that you are taking the CLI and building a workflow on top of it. That is exactly what we wanted to enable!

We are still looking into improving the authorization prompting behaviour. Could you tell me which editor you are using and which feature of that editor your are using to call the CLI? That would allow me to run some tests locally to see if there is anything we can do to make this experience a bit smoother.

Joris

This is emacs, using M-x compile.

That said, I would expect any editor that can be programmed to shell out to run tasks would use a new TTY for each run, and presumably also reset whatever 'session start time' is being described in the above document (what is that?).

Thank you for providing those details. I am now able to reproduce what you are describing. You are correct that emacs is using a new TTY for each compile command it runs. Since authorization for the CLI is stored for a specific TTY, authorization does not carry over between commands.

Unless there is a way for for emacs to not use a new TTY for each compile command it executes, it will be tricky to solve this without making some impactful changes to the security model.

I have filed an issue for myself to dig into this a bit further to see if there is something we can do without compromising on security for other use-cases.

and presumably also reset whatever 'session start time' is being described in the above document (what is that?).

It's the time at which the process that is the session leader (the process with a process ID that equals the session ID, see the https://man7.org/linux/man-pages/man7/credentials.7.html for more details if you're interested) originally started. We use it to uniquely identify a session. The reason why we add the start time, is that the ID of a session can be reused after all processes in a session are terminated. We do not want previously granted authorization to carry over to this new session, so we also add the start time into the mix.

This model is based on what sudo does internally to cache its authorization.

Thanks for digging in! I do hope you can find a solution. I'm eager to use the new biometric auth support; I currently stash the OP_SESSION env variable in the keychain and would love to start using biometric auth instead: https://github.com/apiology/with-op

You're welcome. Thanks for sharing your feedback!