PROTECTED]
To: [EMAIL PROTECTED]
Subject: [PROPOSAL] dpkg-statoverride and Conflicts: suidmanager (<< 0.50)
X-Face: -eDkx0I[vNsajBStK^((#;s#wZr+;?Up|;+Zw5JOl]'fINagA)&i4=$2WI'z4U!h0>;A3ON
RW{7o6imB12xD.pSBhFoqTuF{>b9[K[R\0h=c]Yy6h_R"=Ogv~9
EsgE,9_6?%yFG'C6&
> "Manoj" == Manoj Srivastava <[EMAIL PROTECTED]> writes:
Manoj> I disagree. Developers reference still exists, and so
Manoj> does the packaging manual. The packaging manual is merely
Manoj> no longer policy.
There is no link to the packaging manual from w.d.o/devel and there
>>"Ben" == Ben Gertzfield <[EMAIL PROTECTED]> writes:
> "Wichert" == Wichert Akkerman <[EMAIL PROTECTED]> writes:
Wichert> Policy should set guidelines for making packages [...]
Wichert> The less details, the better.
Ben> Um. Policy *IS* the guide for making packages now. There's no
Be
On Fri, Mar 16, 2001 at 09:43:01PM +1100, Herbert Xu wrote:
> Julian Gilbey <[EMAIL PROTECTED]> wrote:
>
> > Yes, when I started this thread, I hadn't thought of this case. But
> > I've now become convinced of the need to have a distinction between
> > maintainer statoverrides, for cases like thi
Julian Gilbey <[EMAIL PROTECTED]> wrote:
> Yes, when I started this thread, I hadn't thought of this case. But
> I've now become convinced of the need to have a distinction between
> maintainer statoverrides, for cases like this, and local
> statoverrides, which take precedence.
Not necessarily,
On Thu, Mar 15, 2001 at 01:54:08PM -0300, Henrique M Holschuh wrote:
> Have you noticed you're advocating creating dynamic users in just about
> every machine that ever needs to build a certain package JUST because you
> dislike dpkg-statoverride usage in postinst? It looks like you're trying to
>
ster, instead, users
>> can use dpkg-statoverride as necessary.
>>
>> Policy (section 11.9, "Permissions and Owners") doesn't talk about
>> either way, but it should mention that suidregister should no longer
>> be used; also, that packages previously
On Thu, 15 Mar 2001, Henrique M Holschuh wrote:
> every machine that ever needs to build a certain package JUST because you
> dislike dpkg-statoverride usage in postinst? It looks like you're trying to
That was out of line, and I apologise. Please read "JUST because of a
dislike...", and "looks l
On Thu, 15 Mar 2001, Anthony Towns wrote:
> On Thu, Mar 15, 2001 at 01:15:37PM +0100, Wichert Akkerman wrote:
> > Previously Anthony Towns wrote:
> > > What's special about dynamic u/gids? You just make sure the user/group
> > > exists in the preinst, then let dpkg unpack it to the correct id. No n
Previously Anthony Towns wrote:
> Seems like either fakeroot could be enhanced to handle that, or maybe
> such packages should be restricted to being built with sudo with the
> appropriate checks in debian/rules to ensure that either the user already
> exists, or that running adduser in debian/rule
l and package overrides, in the way that
> > > suidmanager used to do?
> > There are only local overrides now.
> It would be nice to have a facility for packages to introduce
> overrides when dynamic user/group ids are involved, which would take a
> lower precedence than sysa
On Thu, Mar 15, 2001 at 01:15:37PM +0100, Wichert Akkerman wrote:
> Previously Anthony Towns wrote:
> > What's special about dynamic u/gids? You just make sure the user/group
> > exists in the preinst, then let dpkg unpack it to the correct id. No need
> > for statoverrides at all.
> The name of th
Previously Anthony Towns wrote:
> What's special about dynamic u/gids? You just make sure the user/group
> exists in the preinst, then let dpkg unpack it to the correct id. No need
> for statoverrides at all.
The name of the user/group must be used in the data.tar.gz, which can
only happen if the
On Wed, Mar 14, 2001 at 01:29:56PM +0100, Wichert Akkerman wrote:
> Previously Julian Gilbey wrote:
> > Is there any easy way in which dpkg-statoverride can be modified to
> > distinguish between local and package overrides, in the way that
> > suidmanager used to do?
>
On 13-Mar-01, 13:05 (CST), Ben Gertzfield <[EMAIL PROTECTED]> wrote:
> > "Wichert" == Wichert Akkerman <[EMAIL PROTECTED]> writes:
>
> Wichert> Policy should set guidelines for making packages [...]
>
> Wichert> The less details, the better.
>
> Um. Policy *IS* the guide for making
Previously Julian Gilbey wrote:
> Is there any easy way in which dpkg-statoverride can be modified to
> distinguish between local and package overrides, in the way that
> suidmanager used to do?
There are only local overrides now.
uish between local and package overrides, in the way that
suidmanager used to do?
Julian
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
Debian GNU/Linux Developer, see http://peop
> "Wichert" == Wichert Akkerman <[EMAIL PROTECTED]> writes:
Wichert> What exactly do you want in policy? `if you behave like
Wichert> the old suidregister don't do this' or so? I really don't
Wichert> see the use of that.
The conflicts that man dh_suidregister mentions should be i
Previously Ben Gertzfield wrote:
> That's a good usage, but for the "old" suidregister-like behavior,
> normal SUID/SGID apps do *not* need to be dpkg-statoverride'd,
> as far as I can tell. That's all I want to get in policy; we
> should mention that it's OK for dynamic users/groups.
What exactl
> "Wichert" == Wichert Akkerman <[EMAIL PROTECTED]> writes:
Wichert> Policy should set guidelines for making packages [...]
Wichert> The less details, the better.
Um. Policy *IS* the guide for making packages now. There's no
Packaging Manual any more, and so these kinds of details
> "Wichert" == Wichert Akkerman <[EMAIL PROTECTED]> writes:
Julian> dpkg-statoverride --list is OK, adding or removing
Julian> overrides is almost certainly not.
Wichert> It most certainly is. Think dynamic useres and groups,
Wichert> user interaction if debconf isn't availabl
Previously Julian Gilbey wrote:
> But you mustn't use dpkg-statoverride to introduce new overrides;
> that's the responsibility of the local sysadmin.
That is a vlid point, but has nothing to do with where you use
dpkg-statoverride.
I don't think policy should mention where you can use it. Policy
On Tue, 13 Mar 2001, Julian Gilbey wrote:
> On Tue, Mar 13, 2001 at 11:56:59AM -0300, Henrique M Holschuh wrote:
> > On Mon, 12 Mar 2001, Ben Gertzfield wrote:
> > > If I understand dpkg-statoverride correctly, mentioning that
> > > dpkg-statoverride is not to be called from maintainer post/pre
> >
Previously Julian Gilbey wrote:
> dpkg-statoverride --list is OK, adding or removing overrides is almost
> certainly not.
It most certainly is. Think dynamic useres and groups, user interaction
if debconf isn't available, etc.
Wichert.
--
On Tue, Mar 13, 2001 at 02:21:47PM +0100, Wichert Akkerman wrote:
> Previously Ben Gertzfield wrote:
> > If I understand dpkg-statoverride correctly, mentioning that
> > dpkg-statoverride is not to be called from maintainer post/pre
> > install scripts should also be added.
>
> Euhm, how did you c
On Tue, Mar 13, 2001 at 11:56:59AM -0300, Henrique M Holschuh wrote:
> On Mon, 12 Mar 2001, Ben Gertzfield wrote:
> > If I understand dpkg-statoverride correctly, mentioning that
> > dpkg-statoverride is not to be called from maintainer post/pre
> > install scripts should also be added.
>
> I oppo
On Mon, 12 Mar 2001, Ben Gertzfield wrote:
> If I understand dpkg-statoverride correctly, mentioning that
> dpkg-statoverride is not to be called from maintainer post/pre
> install scripts should also be added.
I oppose that. How am I supposed to have dynamically-created UIDs [that are
not created
Previously Ben Gertzfield wrote:
> If I understand dpkg-statoverride correctly, mentioning that
> dpkg-statoverride is not to be called from maintainer post/pre
> install scripts should also be added.
Euhm, how did you come to that conclusion?
Wichert.
--
ers
> can use dpkg-statoverride as necessary.
>
> Policy (section 11.9, "Permissions and Owners") doesn't talk about
> either way, but it should mention that suidregister should no longer
> be used; also, that packages previously using suidregister should
> Conflict: wi
esn't talk about
either way, but it should mention that suidregister should no longer
be used; also, that packages previously using suidregister should
Conflict: with suidmanager (<< 0.50).
If I understand dpkg-statoverride correctly, mentioning that
dpkg-statoverride is not to be called
On Tue, Feb 10, 1998 at 12:51:09PM -0800, Karl M. Hegbloom wrote:
> > BTW, I hope lintian will check that all the suid files are
> > registered with suidmanager..
> An issue then being that `suidmanager' must be one of the first
> things to get installed. Should
>>>>> "Tommi" == Tommi Virtanen <[EMAIL PROTECTED]> writes:
> BTW, I hope lintian will check that all the suid files are
> registered with suidmanager..
An issue then being that `suidmanager' must be one of the first
things to get installed. Should it then be part of the base set?
32 matches
Mail list logo
