On Wed, Aug 17, 2005, Matthias Kurz wrote:
> Shouldn't all packages that use r_usr and/or r_grp get an option to
> specify a "real" user/group ? Else, when someone gains access to one
> package that uses r_usr/r_grp, he would also have access to files from
> other packages. Also, this may support people who are "used" to use
> special (common) users for such cases.
We have those with_{user,group} options just in "amanda", "bacula"
and one more package I cannot remember. And to be honest, the whole
with_{user,group} I just accepted in those few packages because people
wished it multiple times and I got tired of arguing and thought "well,
it doesn't really hurt in those few packages, so ok".
But the problem with those options is:
1. If we provide options for overwriting l_{m,r,n}{usr,grp} variables
why don't we provide options for all those other nice l_xxx
variables. By being a little bit crazy, why not also wishing to
change l_prefix on the fly? In other words my problem is that those
options kill orthogonality in the set of existing options (which are
except for a few exceptions mostly feature enabling options but never
change the behavior of the packaging system).
2. Those options open the intentionally closed and self-contained
security scope (all packages use just those four, pre-selected and
then fixed users/groups) of OpenPKG. This way the admin too easily
can "open a can of worms" because new security implications (through
different access to files, etc) are caused by using different
users/groups than the packager intended.
3. I understand that were introduced because people this way wish
to solve some permission problems between OpenPKG and non-OpenPKG
applications. But at the cost of hacks within OpenPKG. I usually
prefer other technical workarounds (setuid wrappers, etc) instead of
directly affecting OpenPKG.
Hence I personally strongly vote for not introducing those overwrite
options and at the same time even kick out the existing ones (plus
perhaps add some other hooks which allow the people to still solve their
problems, of course).
If we really come to the conclusion that those options are absolutely
necessary, then we should at least think about orthogonality and
completeness and instead of adding with_{user,group} options to each
package we should use a more general RPM mechanism overwrite all those
variables (--define "l_usr xxx") plus add the possibility to make them
sticky throughout upgrades.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
______________________________________________________________________
The OpenPKG Project www.openpkg.org
Developer Communication List openpkg-dev@openpkg.org
