|
Home > Archive > Debian Developers > March 2004 > dpkg-statoverride: Do I need a cluebat?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
dpkg-statoverride: Do I need a cluebat?
|
|
| Andreas Barth 2004-03-13, 6:34 pm |
| Hi,
I'm just plaguing myself with dpkg-statoverride, and I have one
fundamental question: Do I have a silly problem and need a cluebat, or
is dpkg-statoverride broken by design?
What I want to do: I have a package that had different stati for one
directory via dpkg-statoverride. So, I need to force some setting
under special conditions. However, I don't want to override
sysadmins settings.
What I don't understand is, why there are not two levels of
dpkg-statoverride, one for the maintainer and one for the admin.
Furthermore, dpkg-statoverride could even read the maintainer
information from package.statoverride. This would have the advantage
that there is no need to use constructs like:
if ! dpkg-statoverride --list /usr/lib/games/nethack/recover >/dev/null
then
dpkg-statoverride --add root games 2755 /usr/lib/games/nethack/recover
fi
but just to put the file in the right place, call a
dpkg-statoverride --update nethack
and I'm done. Local admins changes would have automatic precedence,
but I wouldn't need to care about them (nor about changes of my stati)
at all.
Well, why is this not done? Can someone hit me with the cluebat?
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Adam Heath 2004-03-13, 9:34 pm |
| On Sat, 13 Mar 2004, Andreas Barth wrote:
> if ! dpkg-statoverride --list /usr/lib/games/nethack/recover >/dev/null
> then
> dpkg-statoverride --add root games 2755 /usr/lib/games/nethack/recover
> fi
maintainers don't use dpkg-statoverride. They set the perms in the .deb,
inside debian/rules.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Daniel Jacobowitz 2004-03-13, 10:34 pm |
| On Sat, Mar 13, 2004 at 10:45:48PM +0100, Andreas Barth wrote:
> Hi,
>
> I'm just plaguing myself with dpkg-statoverride, and I have one
> fundamental question: Do I have a silly problem and need a cluebat, or
> is dpkg-statoverride broken by design?
>
> What I want to do: I have a package that had different stati for one
> directory via dpkg-statoverride. So, I need to force some setting
> under special conditions. However, I don't want to override
> sysadmins settings.
>
> What I don't understand is, why there are not two levels of
> dpkg-statoverride, one for the maintainer and one for the admin.
> Furthermore, dpkg-statoverride could even read the maintainer
> information from package.statoverride. This would have the advantage
> that there is no need to use constructs like:
> if ! dpkg-statoverride --list /usr/lib/games/nethack/recover >/dev/null
> then
> dpkg-statoverride --add root games 2755 /usr/lib/games/nethack/recover
> fi
> but just to put the file in the right place, call a
> dpkg-statoverride --update nethack
> and I'm done. Local admins changes would have automatic precedence,
> but I wouldn't need to care about them (nor about changes of my stati)
> at all.
>
> Well, why is this not done? Can someone hit me with the cluebat?
More precisely, policy 10.9.1:
Given the above, `dpkg-statoverride' is essentially a tool for system
administrators and would not normally be needed in the maintainer
scripts.
The following example about how to use it to manage dynamically
allocated group IDs does seem pretty broken though.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Andreas Barth 2004-03-14, 4:34 am |
| * Adam Heath (doogie@debian.org) [040314 03:25]:
> On Sat, 13 Mar 2004, Andreas Barth wrote:
>
[color=darkred]
> maintainers don't use dpkg-statoverride. They set the perms in the .deb,
> inside debian/rules.
Then there are a lot of broken maintainer scripts around. Furthermore,
this doesn't work with dynamically added user ids. And, Policy tells
in http://www.debian.org/doc/debian-po...es.html#s10.9.1 how
to call dpkg-statoverride in maintainer scripts (though this section
is according to itself not part of policy).
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Andreas Metzler 2004-03-14, 5:33 am |
| Andreas Barth <aba@not.so.argh.org> wrote:
> I'm just plaguing myself with dpkg-statoverride, and I have one
> fundamental question: Do I have a silly problem and need a cluebat, or
> is dpkg-statoverride broken by design?
Yes, probably both, but see below.
> What I want to do: I have a package that had different stati for one
> directory via dpkg-statoverride. So, I need to force some setting
> under special conditions. However, I don't want to override
> sysadmins settings.
[...]
That is exactly the problem with dpkg-statoverride.
Rules of thumb:
* Do not modify overrides in maintainerscripts, ship the permissions
in the deb.
* dpkg-statoverride is for the sysadmin.
* Only "if ! dpkg-statoverride --list ..." is completely ok.
Problems arise if you cannot ship the permissions in the deb,
basically you have some options, depending on the requirenents
* Add a dpkg-statoverride.
* Don't ship empty directory in deb, use mkdir.
* re-set permissions/owner in on ever installation in postinst.
if ! dpkg-statoverride --list /file/foo
#ask for suid with debconf
chmod u+s /file/foo
fi
The latter cannot be used often (especially not for chown for
dynamically allocated UIDs), because usually the package would be
completely broken while upgrading until postinst is run.
dpkgV2 is supposed to include support for shipping files owned by
dynamically allocated UIDs in the deb minimizing the need for
dpkg-statoverride but we won't be able to use that until sarge+2 even
if it was implemented 6 months from now.
cu andreas
--
NMUs aren't an insult, they're not an attack, and they're
not something to avoid or be ashamed of.
Anthony Towns in 2004-02 on debian-devel
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Henrique de Moraes Holschuh 2004-03-14, 8:34 am |
| On Sat, 13 Mar 2004, Adam Heath wrote:
> maintainers don't use dpkg-statoverride. They set the perms in the .deb,
> inside debian/rules.
Current dpkg does not have the required functionality for that to be true.
Maintainer scripts _do_ use dpkg-statoverride. Although, if any such
scripts is updating an existing override, it is probably buggy.
Too bad this thing has no concept of overrides from the local admin, and
overrides from the package, like diversions do. Come to think of it,
why the heck was it implemented without such functionality?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Adam Heath 2004-03-15, 6:34 pm |
| On Sun, 14 Mar 2004, Andreas Metzler wrote:
> Andreas Barth <aba@not.so.argh.org> wrote:
>
> Yes, probably both, but see below.
>
> [...]
>
> That is exactly the problem with dpkg-statoverride.
>
> Rules of thumb:
> * Do not modify overrides in maintainerscripts, ship the permissions
> in the deb.
> * dpkg-statoverride is for the sysadmin.
> * Only "if ! dpkg-statoverride --list ..." is completely ok.
>
> Problems arise if you cannot ship the permissions in the deb,
> basically you have some options, depending on the requirenents
> * Add a dpkg-statoverride.
> * Don't ship empty directory in deb, use mkdir.
> * re-set permissions/owner in on ever installation in postinst.
> if ! dpkg-statoverride --list /file/foo
> #ask for suid with debconf
> chmod u+s /file/foo
> fi
Call adduser in preinst, ship perms in deb as normal.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Andreas Metzler 2004-03-16, 3:34 am |
| Adam Heath <doogie@debian.org> wrote:
[dpkg-statoverride alternatives.]
> Call adduser in preinst, ship perms in deb as normal.
I missed that. - This solution will work for packages with
static-uid/gid[1] in 60000-64999.
To stop misconceptions: It won't work for packages allocationg a user
with dynamically allocated uid using "adduser --system".
cu andreas
PS: Please respect Mail-Followup-To.
[1] See /usr/share/doc/base-passwd/README.
--
NMUs aren't an insult, they're not an attack, and they're
not something to avoid or be ashamed of.
Anthony Towns in 2004-02 on debian-devel
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|