85.1.58. pepsi-helper-auto-pay

drive taler-wallet-cli as the paying user

Section du manuel:

1

85.1.58.1.1. Nom

pepsi-helper-auto-pay - helper privilégié qui tarife ou paie une demande de remise GNU Taler en exécutant taler-wallet-cli en tant que l’utilisateur approprié.

85.1.58.1.2. Synopsis

pepsi-helper-auto-pay OP ( –uid N | –user NAME –wallet-db KEY ) [–wallet-cli PATH] [OP-OPTIONS]

où OP est l’un de preview/pay –uri TALER-URI [–pay-option OPT]…, balance, withdraw –amount CURRENCY:VALUE –exchange URL, push –uri TALER-URI, ou pull –amount CURRENCY:VALUE [–subject TEXT].

85.1.58.1.3. Description

pepsi-helper-auto-pay est un helper minimal et durci en sécurité qui exécute taler-wallet-cli contre exactement un wallet, en tant qu’exactement un utilisateur, pour une seule opération de wallet. Il existe afin qu’un appelant de confiance mais non privilégié (un membre du groupe pepsi-wallets, en pratique pepsi-stage-auto-pay(1)) puisse piloter le wallet approprié — et ne rien faire d’autre.

Les opérations prises en charge sont : preview (tarifer une demande taler://pay/… sans payer) et pay (en régler une) pour le rôle entrant de paiement des demandes ; et balance, withdraw (mettre en place un rechargement manuel contre un exchange), push (accepter un paiement pair entrant taler://pay-push/…) et pull (initier un pull pair, produisant une URI taler://pay-pull/…) pour le rôle self-service de wallet.

Le helper est installé setuid-root, possédé root:pepsi-wallets avec le mode 4750. Seuls les membres du groupe pepsi-wallets peuvent l’exécuter ; lorsqu’ils le font, le noyau l’exécute avec un uid effectif de root. Le helper, ensuite :

  1. résout le compte cible et, en mode partagé, le chemin de la base de données du wallet à l’intérieur du répertoire personnel de ce compte, construit à partir du KEY validé (le chemin ne peut donc jamais sortir du répertoire personnel) ;

  2. abandonne complètement et irréversiblement ses privilèges vers l’utilisateur cible — installe les groupes supplémentaires de l’utilisateur, puis règle le gid, puis l’uid (réel+effectif+sauvegardé), en vérifiant que root ne peut être regagné — refusant l’uid 0 et le login root. En mode local-user, il refuse en outre tout uid inférieur à UID_MIN de /etc/login.defs (1000 lorsque ce fichier ne peut être lu ; on y attend un véritable destinataire) ; le mode shared en est exempté, puisque sa cible est le compte de service WALLET_USER configuré par l’opérateur (par exemple pepsi-wallets, typiquement un uid bas). (Comme pepsi-helper-dot-forward(1) et pepsi-helper-maildir-writer(1), il se dépouille complètement de root.)

  3. exécute taler-wallet-cli — éventuellement avec --wallet-db=… — pour l’opération demandée, avec un environnement construit de zéro, et non filtré : l’enfant ne reçoit que HOME, USER/LOGNAME (le compte cible), un PATH et un SHELL fixes, et rien de ce que l’appelant a passé. Les privilèges ont déjà été abandonnés, de sorte que le chargeur dynamique honore de nouveau LD_PRELOAD/LD_AUDIT, et le wallet est un programme Node.js qui honore NODE_OPTIONS/NODE_PATH ; chaque variable de l’environnement de l’appelant est choisie par l’appelant, de sorte que soustraire les noms connus comme dangereux laisserait « exécuter le wallet en tant qu”alice » atteignable comme « exécuter le code de l’appelant en tant qu”alice » — l’élévation que ce helper existe pour empêcher — et laisserait aussi l’appelant rediriger le trafic du wallet vers l’exchange (https_proxy/SSL_CERT_FILE). En mode shared, le répertoire de base de données de wallet ~NAME/wallets est créé avec le mode 0700 s’il est absent.

    preview demande la proposition à wallet-core (api preparePayForUri) et lit le prix dans les termes du contrat — handle-uri ne peut pas servir à tarifer, puisque sans --yes il s’arrête à une invite de confirmation qui ne se termine pas sur EOF, et n’affiche de toute façon aucun prix. pay exécute handle-uri --choice-index 0 --yes plus les éventuels arguments --pay-option supplémentaires et va jusqu’à son terme (un contrat de version 1 propose une liste de choices et ne peut être payé tant qu’un choix n’est pas nommé ; le premier est celui que preview a tarifé). push demande deux commandes de wallet — p2p prepare-push-credit pour l’identifiant de transaction du paiement entrant, puis p2p confirm-push-credit pour l’accepter (handle-uri ne rend pas la main sur une telle URI, et la purse expirerait donc sans être acceptée). balance, withdraw et pull exécutent les sous-commandes de wallet correspondantes et rapportent leur résultat (le texte du solde, les instructions de virement du retrait, ou l’URI pay-pull). Les sous-commandes taler-wallet-cli exactes sont le seul point dépendant de la version du wallet, isolé dans le helper.

Après un pull, et après l’acceptation d’un push, le helper exécute la boucle de tâches du wallet (run-until-done) pendant une durée bornée (30 secondes). p2p initiate-pull-credit ne fait qu’enregistrer la demande localement, et la purse est créée auprès de l’exchange par cette boucle — tant qu’elle n’a pas tourné, l’URI envoyée à l’utilisateur n’est pas payable du tout, et rien d’autre ne l’exécuterait jamais, puisqu’un wallet par utilisateur ne se réveille que lorsque son propriétaire envoie la commande suivante. La borne existe parce qu’un crédit peer-pull n’est pas « terminé » tant que quelqu’un ne l’a pas payé, sinon la commande attendrait indéfiniment.

Si le wallet signale une exigence KYC (vérification d’identité) pour une opération self-service, le helper extrait l’URL KYC et quitte avec 3 en plaçant l’URL sur la sortie standard, afin que l’étape puisse envoyer le lien par e-mail à l’utilisateur. Cela n’est envisagé que si l’opération n’a produit aucun résultat propre : une opération réussie est rapportée comme un succès même si la sortie de diagnostic du wallet mentionne KYC quelque part, et l’URL est prise dans le texte qui la mentionne plutôt qu’à l’endroit où une URL apparaît en premier.

Les deux modèles de compte sont choisis par l’appelant. Avec –uid, le helper abandonne ses privilèges vers cet uid local et utilise le wallet par défaut de cet utilisateur (WALLET_MODE = local-user dans pepsi-stage-auto-pay(1)). Avec –user et –wallet-db, il abandonne ses privilèges vers le compte partagé nommé (par défaut pepsi-wallets) et pointe le wallet vers ~NAME/wallets/KEY.sqlite3 (WALLET_MODE = shared).

Ce programme n’est pas destiné à être exécuté à la main ; c’est pepsi-stage-auto-pay(1) qui l’invoque. Il est documenté ici en raison de son installation privilégiée.

85.1.58.1.4. Options

preview | pay | balance | withdraw | push | pull

L’opération. preview affiche le prix d’une demande sans payer ; pay la règle ; balance affiche le solde du wallet ; withdraw met en place un rechargement manuel et affiche les instructions de virement ; push accepte un paiement pair entrant ; pull initie un pull pair et affiche l’URI résultante.

–uri TALER-URI

L’URI taler://pay/… (preview/pay) ou taler://pay-push/… (push) sur laquelle agir. Obligatoire pour ces opérations. Elle est revalidée ici, à la frontière privilégiée : preview/pay refusent tout ce qui n’est pas une URI taler://pay/, push tout ce qui n’est pas taler://, et toute URI est refusée d’emblée si elle contient un caractère hors du répertoire de la RFC 3986 (de sorte que guillemets, barres obliques inverses et espaces ne puissent jamais atteindre le wallet).

–amount CURRENCY:VALUE

Le montant GNU Taler, requis pour withdraw et pull.

–exchange URL

L’URL de base de l’exchange pour un withdraw manuel (requise).

–subject TEXT

Un sujet/résumé de paiement facultatif pour pull.

–uid N

Mode local-user : abandonne les privilèges vers l’uid N et utilise le wallet par défaut de cet utilisateur. Mutuellement exclusif avec –user.

–user NAME –wallet-db KEY

Mode partagé : abandonne les privilèges vers le compte NAME et utilise la base de données de wallet nommée par le KEY opaque et validé sous le répertoire personnel de ce compte. Les deux sont requis ensemble.

–wallet-cli PATH

Le binaire taler-wallet-cli à exécuter (par défaut taler-wallet-cli, résolu sur $PATH).

–pay-option OPT

Un argument supplémentaire ajouté à l’invocation pay (répétable, par exemple --run-until-done) ; --yes est également ajouté à pay, puisqu’un helper lancé depuis une étape n’a personne à qui demander.

Ni l’un ni l’autre ne s’applique à push, qui n’est pas du tout un appel handle-uri mais un enchaînement à deux commandes p2p prepare-push-credit / confirm-push-credit : confirm-push-credit rejette purement et simplement ces indicateurs, et la boucle de tâches qu’ils demandent d’ordinaire est de toute façon ce que fait la propre boucle de pilotage du helper. Les options sont acceptées et ignorées sur ce chemin, de sorte qu’un WALLET_PAY_OPTIONS défini pour un push self-service n’a aucun effet.

85.1.58.1.5. Code de sortie

0

Succès. Pour preview, le montant proposé est sur la sortie standard ; pour balance, withdraw et pull, le texte du rapport est sur la sortie standard ; pour pay et push, la sortie standard est vide.

2

L’opération a échoué (mauvais arguments, pas setuid-root, un compte refusé, le prix n’a pas pu être lu, ou l’opération de wallet a échoué). Un diagnostic lisible par un humain est écrit sur la sortie standard et sur l’erreur standard.

3

Le wallet exige un KYC (vérification d’identité) ; l’URL KYC est sur la sortie standard.

85.1.58.1.6. Sécurité

Le helper ne fait délibérément aucun travail de configuration, de base de données ou de journalisation. Sa seule action privilégiée est de devenir l’utilisateur cible avant d’exécuter le wallet ; il refuse d’agir en tant que root et vérifie que root est irrécupérable après l’abandon des privilèges. L’accès à celui-ci est contrôlé par le groupe pepsi-wallets, accordé à l’appelant via le bit SGID de pepsi-stage-auto-pay(1) et à personne d’autre.

85.1.58.1.7. Voir aussi

pepsi-stage-auto-pay(1), pepsi-stage-anti-spam(1), pepsi-helper-dot-forward(1), pepsi-dispatch(1), pepsi.conf(5)

85.1.58.1.8. Bogues

Signalez les bogues au gestionnaire de tickets de Pepsi.