On Sat, Jan 25, 2003, Bill Campbell wrote:
> >> while beeing a nice idea I am not 100% convinced that introducing the
> >> three openpkg users gains much more than it costs.
> ...
> >> Especially when using openpkg to employ deamons (like apache, postfix,...)
> >> it starts to become an annoyance to have the special openpkg users.
> >> (Without root permissions it is difficult to give the directories correct
> >> ownership when installing an openpkg rpm)
> >
> >That's the reason why the _general_ rule in OpenPKG is: build as the
> >management user (%{l_musr}, in your case "cw") and install as the super
> >user (%{l_susr}, in usually all cases "root"). But this has nothing
> >to do with the extra restricted and nobody user/group ids. This is
> >just inherently necessary because daemons have setuid and other stuff
> >which just require super user priviledges. So, sure, for things like
> >Postfix it is _always_ necessary to install as root to result in correct
> >ownerships, etc.
>
> Wouldn't it then make sense with these general rules to have the
> %{l_prefix}/RPM/{SRC,TMP,PKG} directories owned by %{l_musr},%{l_mgrp} and
> everything else by %{l_susr},%{l_sgrp}? As it is now with the default
> ownership of the openpkg hierarchy the management user, developers can
> write into the installation areas, accidentally nuking things just as in
> the traditional RPM environment when everybody builds a root.
>
> I've found some interesting bugs in my old RPM spec files while converting
> to openpkg where I've changed things in the underlying system accidentally.
> On the other hand, I've missed a few where I was able to write into the
> openpkg working (install destination) directories while building as the
> management user.
For OpenPKG there are two scenarios:
1. system-level deployment (i.e. --prefix=/usr/opkg --user=opkg --group=opkg):
l_susr/l_sgrp root/wheel
l_musr/l_mgrp opkg/opkg
l_rusr/l_rgrp opkg-r/opkg-r
l_nusr/l_ngrp opkg-n/opkg-n
2. user-level deployment (i.e. --prefix=/u/rse/opkg --user=rse --group=rse):
l_susr/l_sgrp root/wheel
l_musr/l_mgrp rse/rse
l_rusr/l_rgrp rse/rse
l_nusr/l_ngrp rse/rse
The first is the classical admin system purpose way of installation,
the second is the alternative single-user private purpose way of
installation. It is clear that not all packges work for (2) because
some (e.g. Postfix) require distinct user/group ids or want to bind to
priviledged ports, etc. But 95% of all packages also can be used in
situation (2). And (2) prevents you from installing any files owned by
root/wheel, of course.
Additionally, the management user is really intended to both build and
install the packages, so it is correct that they are owned by him. It is
just because of the 5% of packages from above and the confusion people
would have ("for which package I've to run "rpm -Uvh" as root and for
which I do not?") that we declared the general goal in OpenPKG that "rpm
--rebuild" is performed as the management user and that "rpm -Uvh" is
performed by the super user (although we know that in 95% of the cases
this would be not really necessary, of course).
So, owning the files by the super user would both break situation (2)
and really _technically require_ super user priviledges for "rpm -Uvh"
all the time. And although certainly nasty, the nuking of files during
built-time should be a developer only issue (so does not count that
much) while the other issues are end-user issues (which have to count
more). The OpenPKG project developers build packages actually under
their personal user/group to avoid this nuking easily during package
development. But end-users get tested packages where no such nuking
should exist, so they are usually not affected by the nuking problem --
at least in theory ;-)
But you're right: perhaps we should not even recommend to use the
management user for building, but the nobody user. Hmmm... your points
are worth considering more, because here we have a subtle issue on
which we should investigate more and discuss it in depth. What are the
opinions of others?
> This ties back to my question last week about the security implications of
> running package rc.%{name} files which are writeable by users other than
> root. If the working directories are owned by %{l_susr} (defaulting to
> root), this goes a long way towards securing these scripts. A further step
> would be for the etc/rc script to check the ownership of any files, and
> their directory components running with root priviledges to insure that
> they're only writeable by %{l_susr}.
Perhaps you've missed by reply, but from a security point of view IMHO
we do not gain very much by doing it just this way. Because the problem
is that all rc scripts theirself call other programs, etc. And this way
all the super user ownerships and tests are useless as long as just a
single program of this is not owned by the super user, aren't they?
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
______________________________________________________________________
The OpenPKG Project www.openpkg.org
Developer Communication List [EMAIL PROTECTED]
