[Pkg-privacy-maintainers] Bug#911907: [monkeysphere] Bug#911907: Bug#911907: monkeysphere: Install fails on systems with PAM login restrictions

[Daniel Kahn Gillmor]

Hi Sunil--

thanks for all your work on this.  i think we're heading for a
significant improvement here :)

On Mon 2018-10-29 00:35:53 -0700, Sunil Mohan Adapa wrote:
> runuser does not seem to depend on the user's shell. It simply runs a
> given process under that user's id (with a different PAM configuration).
>  This is better at least for the purposes we are using it. Whenever
> evaluating bash expressions as a user, we are already doing
> 'su_monkeysphere_user bash -c "<EXPR>"'.
>
> # usermod -s /usr/sbin/nologin monkeysphere
> # su monkeysphere ls
> This account is currently not available.
> # runuser --user monkeysphere ls
> <output>

reading the documentation for runuser:

       -s, --shell=shell
              Run  the  specified  shell instead of the default.  The shell to
              run is selected according to the following rules, in order:

                 o      the shell specified with --shell

                 o      the shell specified in the environment variable  SHELL
                        if the --preserve-environment option is used

                 o      the  shell  listed  in  the passwd entry of the target
                        user

                 o      /bin/sh

              If the target user has a restricted shell (i.e.  not  listed  in
              /etc/shells)  the --shell option and the SHELL environment vari‐
              ables are ignored unless the calling user is root.


which of these cases do you think is triggering the shell selection in
run_as_monkeysphere_user?

> I am additionally proposing another patch which will remove the shell
> for the monkeysphere user in Debian packaging. This closes #901489. We
> don't need the monkeysphere user's shell.

Interesting, thanks!

> I didn't test all the situations before, but in this round I did. I ran
> all commands with bash -x and ensured that every invocation of the
> method in all branches was indeed triggered.
>
> I explicitly changed the name of the method to
> 'run_as_monkeysphere_user' and changed all invocations to make them
> reflect the changed semantics and also to see the full impact.

Thanks, this is a good move.

> All the invocations fall into the these categories:
>
> 1) Simple invocation of gpg/openpgp2ssh command without passing
> environment variables and shell expressions. There is no issues here.
>
> 2) Execution of bash snippets. All of these executions where already
> wrapped with bash -c "<EXPR>". So they all work as is with runuser.
>
> 3) Execution of commands with environment variable passing. Since
> runuser preserves environment from the parent process, we can now say
> `KEY=VALUE runuser -u monkeysphere gpg` instead of the shell expression
> `su monkeysphere KEY=VALUE gpg`. I have updated the patch to handle
> these situations properly.
>
> # TESTVAR1='Hello!' runuser -u monkeysphere -- bash -c 'set' |grep TESTVAR1
> TESTVAR1='Hello!'

while we certainly *can* do this, this change means that runuser itself
will see the changed environment variable, which might affect runuser's
behavior, or the behavior of the (arbitrary, unknown!) pam stack that
runuser executes.  Is that really a desirable outcome?  in general, i'd
lean toward the smallest perturbation possible.  Can we avoid that
problem?

What if we replaced "su_monkeysphere_user KEY=value foo arg" with
"run_as_monkeysphere_user env KEY=value foo arg" instead?

> 4) Redirection expressions like what you have described above currently
> do not exist. I added documentation that bash expressions should not be
> run using the method.

I didn't mean to imply that redirection was the only thing.  what about
other shell metacharacters, like ';' or '||' ?

When you say "no shell expressions" in the comments, does that include
function invocations? variable assignments?

> PS: I ran into issues with TMPDIR as described in #656750 and I am
> currently working around them.

hm, this sounds like it might be an interaction across your changes made
to point 3, above, but i'm not sure how.  can you explain the issues
you're running into in more detail?  can you explain your workaround?

thanks for working on this!

       --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-privacy-maintainers/attachments/20181029/e0e76fe4/attachment.sig>