DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=subject:from:to:cc:in-reply-to:references:content-type:date
         :message-id:mime-version:x-mailer:content-transfer-encoding;
        b=GJ2+ifuZVSpZ1QAYxaurxCSwdbHOfhjPKBDyROOUtyrmSqmJd5GmDlwdg4N7TiwCVl
         iS0i4T9qdKRjb1GKCR5fNl6CiTcJqY8T/DNrSTNKCS1kMUdHyNv8h0g5KUsVyjE1h503
         Wl3sgTJrr0eViXWMZ42ir4OJjjtCD9by5svSw=
Subject: Re: [alpine-devel] extra/tinyproxy
From: Natanael Copa <natanael.copa@gmail.com>
To: Michael Mason <ms13sp@gmail.com>
Cc: alpine-devel@lists.alpinelinux.org
In-Reply-To: <A0C95C40-8D2A-4FAB-936D-8930E17649FF@gmail.com>
References: <A0C95C40-8D2A-4FAB-936D-8930E17649FF@gmail.com>
Content-Type: text/plain
Date: Tue, 24 Feb 2009 11:25:33 +0100
Message-Id: <1235471133.30895.135.camel@nc>
Precedence: list
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Tue, 2009-02-24 at 03:08 +0000, Michael Mason wrote:
> Please commit tinyproxy files.

cool!! thanks!

> This patch also included the install file. I hope this is the way to  
> do this.

yeah thats the way to include them.

> Thx
> 
> 
> 
> 
> 
> 
> 
> 
> differences
> between files
> attachment
> (0001-extra-tinyproxy-Initial-commit-of-file.patch)
> 
> From 75b74a849250335181198e32ec9df00edb2d49bf Mon Sep 17 00:00:00 2001
> From: Michael Mason <ms13sp@gmail.com>
> Date: Tue, 24 Feb 2009 03:04:18 +0000
> Subject: [PATCH] extra/tinyproxy Initial commit of file
> 
> ---
>  extra/tinyproxy/APKBUILD          |   34
> ++++++++++++++++++++++++++++++++
>  extra/tinyproxy/tinyproxy.confd   |    9 ++++++++
>  extra/tinyproxy/tinyproxy.initd   |   39
> +++++++++++++++++++++++++++++++++++++
>  extra/tinyproxy/tinyproxy.install |   30 ++++++++++++++++++++++++++++
>  4 files changed, 112 insertions(+), 0 deletions(-)
>  create mode 100644 extra/tinyproxy/APKBUILD
>  create mode 100644 extra/tinyproxy/tinyproxy.confd
>  create mode 100644 extra/tinyproxy/tinyproxy.initd
>  create mode 100644 extra/tinyproxy/tinyproxy.install
> 
> diff --git a/extra/tinyproxy/APKBUILD b/extra/tinyproxy/APKBUILD
> new file mode 100644
> index 0000000..2bca721
> --- /dev/null
> +++ b/extra/tinyproxy/APKBUILD
> @@ -0,0 +1,34 @@
> +# Contributor: Michael Mason <ms13sp@gmail.com>
> +# Maintainer: Michael Mason <ms13sp@gmail.com>

I'd just like to clarify one thing. The Maintainer the the person
responsible for the package. If someone find a bug in package or wnat
upgrade it to a newer version, then its up to the maintainer to do so. I
will forward bugs to the maintainer and expect a patch. (maintainers
might also be committers once they pren that they can deal with git
properly - until then I will verify and commit)

So generally, I love when you take reponsability for pacakges and want
maintain them. But please be aware that I expect you to take
reponsability for those packages you want to maintain.

So prefferible, you should only maintain packags that you actually use
yourself or have capacity to install and test and verify they work.

I need to be able to trust that when i get a patch from a maintainer,
he/she have verified that package works before he send me a patch. If I
ship a release with a broken package it will be the "maintainers" fault.

So again, thank you very much for stepping up and taking responsability
for packages. But be aware of whats expected from you afterwards. If you
are not up to it, then please remove yourself as Maintainer. (you are
ofcourse still the Contributor)

> +pkgname=tinyproxy
> +pkgver=1.6.3
> +pkgrel=0
> +pkgdesc="Lightweight HTTP proxy"
> +url="https://www.banu.com/tinyproxy/"
> +license="GPL"
> +depends="uclibc"
> +makedepends=""
> +install="tinyproxy.install"
> +subpackages="$pkgname-doc"
> +source="http://downloads.sourceforge.net/$pkgname/$pkgname-$pkgver.tar.gz
> +       tinyproxy.initd
> +       tinyproxy.confd
> +       $install
> +       "
> +
> +build() {
> +       cd "$srcdir/$pkgname-$pkgver"
> +
> +       ./configure --prefix=/usr \
> +               --sysconfdir=/etc \
> +               --mandir=/usr/share/man \
> +               --infodir=/usr/share/info
> +       make || return 1
> +       make DESTDIR="$pkgdir" install

This apkbuild does not install the init.d file or conf.d.

> +
> +}
> +
> +md5sums="bd14d029b12621bcfd7ee71b2f4893da  tinyproxy-1.6.3.tar.gz
> +d0c708403940c51e52eb27ea1610a27d  tinyproxy.initd
> +431dfe7403323e247a88b97beade5d78  tinyproxy.confd
> +b730b3d200f52027868378ad5ee0226b  tinyproxy.install"
> diff --git a/extra/tinyproxy/tinyproxy.confd
> b/extra/tinyproxy/tinyproxy.confd
> new file mode 100644
> index 0000000..0abb80c
> --- /dev/null
> +++ b/extra/tinyproxy/tinyproxy.confd
> @@ -0,0 +1,9 @@
> +# Sample conf.d file for alpine linux
> +
> +#
> +# Specify daemon $OPTS here.
> +#
> +
> +OPTS=""
> +USER="nobody"
> +GROUP="nobody"

The reason to run a daemon as a separate user is that if the service
gets compromised and an attacker manages to execute code, he will not
have more right than the daemon is running as.

Now, if all daemon runs as nobody, and a service gets compromised, it
means that the attacker have the permissions to fiddle with all other
services as well. therefore I prefer that each service have their own
user, rather than everyone runs as nobody. This is how Gentoo does it.

I am open to have 1 user per service (ie, both lighttpd and mini_httpd
runs as a user called "www", all ftp servers runs as a user called ftp
etc) since you nomrlaly pick one webserver, one sql server and one dns
server.

That said... the upstream tinyproxy defaults to use nobody:nogroup.
Sticking to that will reduce our patching.

In the 1.7/1.8 series we have been following the gentoo style, one user
per package. But as said, i open for discussion here.

I see the following alternatives:

1. use gentoo/alpine 1.8 style, 1 user per daemon/package. 
benefits: slightly more secure. compatible with older alpine. (upgrades
should not cause any bigger problems)
drawbacks: we need to create users via .install scripts, more patching
of default config files.

2. have one user per service (debian style?).
benefits: still secure. we can have more system default users. (www
user, dns user, ftp user etc) so fewer packages will need an install
script to create users. Still pretty secure since you most likely dont
run 2 different implementations of same service (ie your run either
lighttpd or mini_httpd. not both)
drawbacks: might still need some patching in the default config files.
upgrading from 1.8 will most likely be painful as the existing
configfiles will need to be modified in many cases.

3. user whatever is default in upstream
benefits. less patching = less work. we stay closer to whatever upstream
recommends/have as default.
drawbacks: upstream might use "nobody" by default and it reduces
security slightly if everythign runs a s "nobody" (attacker have access
of the other services running as nobody). Upgrading from 1.8 will be
painful for same reason as #2.

Ideas here? thoughts?

> diff --git a/extra/tinyproxy/tinyproxy.initd
> b/extra/tinyproxy/tinyproxy.initd
> new file mode 100644
> index 0000000..980c53e
> --- /dev/null
> +++ b/extra/tinyproxy/tinyproxy.initd
> @@ -0,0 +1,39 @@
> +#!/sbin/runscript
> +
> +# Sample init.d file for alpine linux.
> +
> +NAME=
> +DAEMON=/usr/sbin/$NAME

this looks wrong. NAME is empty...

> +
> +depend() {
> +       need net
> +}
> +
> +start() {
> +       ebegin "Starting ${NAME}"
> +               start-stop-daemon --start --quiet --background \
> +                       --make-pidfile --pidfile /var/run/${NAME}.pid
> \
> +                       --chuid ${USER}:${GROUP} \
> +                       --exec ${DAEMON} -- ${OPTS}

...which means this script tries to start /usr/sbin/.

this is broken.

We normally just rip the gentoo init.d script. They tend to work. Most
of them owrked unmodified in 1.7/1.8.


> +       eend $?
> +}
> +
> +stop() {
> +       ebegin "Stopping ${NAME}"
> +               start-stop-daemon --stop --quiet \
> +                       --exec ${DAEMON} \
> +                       --pidfile /var/run/${NAME}.pid \
> +       eend $?
> +}
> +
> +reload() {
> +       ebegin "Reloading ${NAME}"
> +       if ! service_started "${NAME}" ; then
> +               eend 1 "${NAME} is not started"
> +               return 1
> +       fi
> +       start-stop-daemon --stop --oknodo --signal HUP \
> +               --exec ${DAEMON} --pidfile /var/run/${NAME}.pid
> +       eend $?
> +}
> +
> diff --git a/extra/tinyproxy/tinyproxy.install
> b/extra/tinyproxy/tinyproxy.install
> new file mode 100644
> index 0000000..a05d28b
> --- /dev/null
> +++ b/extra/tinyproxy/tinyproxy.install
> @@ -0,0 +1,30 @@
> +#!/bin/sh
> +
> +case "$1" in
> +       pre_install)
> +       # add something which happends before install
> +       # $2 contains package version
this script does nothing here...

> +       ;;
> +       post_install)
> +       # add something which happends after install
> +       # $2 contains package version
nothing here

> +       ;;
> +       pre_upgrade)
> +       # add something which happends before update
> +       # $2 contains new package version
> +       # $3 contains old package version
nothing here

> +       ;;
> +       post_upgrade)
> +       # add something which happends after update
> +       # $2 contains new package version
> +       # $3 contains old package version
nothing here

> +       ;;
> +       pre_deinstall)
> +       # add something which happends before delete
> +       # $2 contains package version
nothing here

> +       ;;
> +       post_deinstall)
> +       # add something which happends after delete
> +       # $2 contains package version
and nothing here.
> +       ;;
> +esac

The install scripts was not needed here at all since it does nothing.

the purpose of install scripts is to do stuff that needs to be
before/after package is installed/upgraded or removed, things like
creating users needed by package.

so yes, there should probaly be an install script here and it should
probably create a user called "tinyproxy"

would be nice if you guys also tested the packages before posting them
here, or atleast put them in testing/ and say that its untested and need
testing.

things in core and extra are expected to work.

I committed the patch and spent the time to fix it and test that it
worked.

thanks!

> -- 
> 1.6.1.3



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---