1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36
|
Source: gosu
Section: admin
Priority: extra
Maintainer: pkg-go <pkg-go-maintainers@lists.alioth.debian.org>
Uploaders: Tianon Gravi <tianon@debian.org>
Build-Depends: debhelper-compat (= 13),
dh-golang (>= 1.10~),
golang-github-opencontainers-runc-dev (>= 1.0.0~rc93~),
golang-go (>= 2:1.15~)
Standards-Version: 4.5.1
Homepage: https://github.com/tianon/gosu
Vcs-Git: https://salsa.debian.org/go-team/packages/gosu.git
Vcs-Browser: https://salsa.debian.org/go-team/packages/gosu
XS-Go-Import-Path: github.com/tianon/gosu
Package: gosu
Architecture: linux-any
Depends: ${misc:Depends}, ${shlibs:Depends}
Built-Using: ${misc:Built-Using}
Description: Simple Go-based setuid+setgid+setgroups+exec
This is a simple tool grown out of the simple fact that "su" and "sudo" have
very strange and often annoying TTY and signal-forwarding behavior. They're
also somewhat complex to setup and use (especially in the case of "sudo"),
which allows for a great deal of expressivity, but falls flat if all you need
is "run this specific application as this specific user and get out of the
pipeline".
.
The core of how "gosu" works is stolen directly from how Docker/libcontainer
itself starts an application inside a container (and in fact, is using the
"/etc/passwd" processing code directly from libcontainer's codebase).
.
Once the user/group is processed, we switch to that user, then we "exec" the
specified process and "gosu" itself is no longer resident or involved in the
process lifecycle at all. This avoids all the issues of signal passing and TTY,
and punts them to the process invoking "gosu" and the process being invoked by
"gosu", where they belong.
|