Rejected: Bug#203650: Poor recommendation in dpkg-statoverride section
This proposal concerns packages that need to have files owned by a dynamically created user. Currently, Policy recommends use of dpkg-statoverride in postinst to change the ownership to the dynamically created user after the user has been created. This Policy proposal would instead create the user in preinst and ship the package with files already owned by the dynamic user (by name) in the *.deb file so that when it was unpacked, the files would already be correctly owned. In the discussion of this proposal, multiple problems were identified, ranging from needing to Pre-Depend on adduser to the difficulty of creating Debian packages with files owned by a dynamically created user. So far as I can tell from the bug log, none of those problems have been addressed and making this change would still be quite challenging from a technical perspective. Given that the Policy change is premature until the technical difficulties with implementing this change have been ironed out, I'm rejecting this proposal at this time. Anyone is welcome to re-propose this change once the technical problems have been resolved (assuming that there is consensus to do the technical work that this change would require). -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#203650: Poor recommendation in dpkg-statoverride section
On Fri, Aug 01, 2003 at 02:05:02AM -0400, Joey Hess wrote: Andrew Suffield wrote: Hold that thought. We hashed out a few ideas on IRC; more in a few days. Meanwhile, let's assume it will be solved... anything else? I missed that discussion, but the obvious approach in fakeroot is user autovivification (to bottow a term from perl) on chown. Or getpwnam(), maybe? How that'd mix in with getpwent() might be confusing. Debian packages aren't necessarily built under fakeroot, though, so this can't necessarily be relied on. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?'' pgpekTm1rRR1L.pgp Description: PGP signature
Bug#203650: Poor recommendation in dpkg-statoverride section
On Mon, Aug 04, 2003 at 10:37:53PM -0500, Adam Heath wrote: On Tue, 5 Aug 2003, Herbert Xu wrote: On Mon, Aug 04, 2003 at 11:05:54AM -0500, Adam Heath wrote: You're confusing pre-depends and essentialness. What about the case if adduser needs a new feature in useradd and thus uses a versioned dependency on passwd. This means that the new adduser can be unpacked before the new passwd is unpacked or configured since it's only a plain old dependency. As an unversioned pre-dependency is fulfilled as long as a package was previously configured, this will allow packages declaring pre-dependencies on adduser to run their preinsts even though the new passwd is not yet available, rendering adduser useless. No. If foo pre-depends on bar, dpkg guarantees that bar is in a configured state, before it even considers doing anything with foo. And foo can only be in a configured state, if all it's normal deps(conflicts/etc) are sane. Please, get your dependency resolution straight. This is not rocket science. Adam, the depisok() function in dpkg 1.10.10 says: * allowunconfigd should be non-zero during the `Pre-Depends' checking * before a package is unpacked, when it is sufficient for the package * to be unpacked provided that both the unpacked and previously-configured * versions are acceptable. The code in this function and in predeppackage() appears to agree. Furthermore, this behaviour is what is described in policy. Herbert seems to be quite correct. -- Colin Watson [EMAIL PROTECTED]
Bug#203650: Poor recommendation in dpkg-statoverride section
On Sun, Aug 03, 2003 at 07:05:44PM -0400, Joey Hess wrote: Jakob Bohm wrote: Note that only a few packages will need these dependencies, unlike libc6. Specifically, these packages will be needed by a subset of the packages that currently Depends: adduser . You have to depend on adduser? Oops. Adjust your numers accordingly. :-) Hmm, I thought they would have to, as adduser is not an Essential package. However, the main point is, that unlike libc6, the number of packages that need to add system users or groups at install time, can be reasonably expected to be a relatively small subset of the entire package pool. I don't have a local Debian mirror, so I do not have the ability to compute statistics based on things not found in the Packages and Contents files, however amongst packages installed on one of my systems, I find the following: apache-ssl Oops, no dependency on adduser dictdOops, no dependency on adduser gdm Does Depends: adduser ssh Does Depends: adduser That is 4 out of 840 installed packages (this is a woody system, mostly desktop and development). So, rough guess is twice as few packages involved. Jakob -- This message is hastily written, please ignore any unpleasant wordings, do not consider it a binding commitment, even if its phrasing may indicate so. Its contents may be deliberately or accidentally untrue. Trademarks and other things belong to their owners, if any.
Bug#203650: Poor recommendation in dpkg-statoverride section
On Mon, Aug 04, 2003 at 07:20:51AM +1000, Herbert Xu wrote: On Sun, Aug 03, 2003 at 10:23:10PM +0200, Jakob Bohm wrote: Also, careful examination of the adduser implementation in woody indicates that the package really only needs its dependencies to be unpacked, at least to add system users and groups. The configure steps of adduser, passwd, and perl-base apparently only change things not affecting that particular operation. Can you really guarantee that this will be the case in future? Not at all, I don't maintain adduser, I was just offering some research on the extent of the issue, as contrasted against the huge number of packages that need libc6 to be available at all times. I do note, however, that the author of adduser seems to have included specific code to ensure operation even when faced with certain classes of broken systems. Remember when perl broke during the libdb upgrade? I heard it was nasty (fortunately I was not tracking the affected branch at the time). -- This message is hastily written, please ignore any unpleasant wordings, do not consider it a binding commitment, even if its phrasing may indicate so. Its contents may be deliberately or accidentally untrue. Trademarks and other things belong to their owners, if any.
Bug#203650: Poor recommendation in dpkg-statoverride section
Jakob Bohm [EMAIL PROTECTED] writes: dictdOops, no dependency on adduser dictd has depended on adduser since 1.7.1-1, which was uploaded 9 July 2002 . Regards, Bob -- _ |_) _ |_Robert D. Hilliard[EMAIL PROTECTED] |_) (_) |_) 1294 S.W. Seagull Way [EMAIL PROTECTED] Palm City, FL 34990 USA GPG Key ID: 390D6559
Bug#203650: Poor recommendation in dpkg-statoverride section
On Sun, Aug 03, 2003 at 11:49:43AM +0100, Julian Gilbey wrote: Then change the line in the postinst: + if [ $1 = configure ] + then for i in /usr/bin/foo /usr/sbin/bar do - if ! dpkg-statoverride --list $i /dev/null + if [ dpkg --compare-versions $2 lt 2.3.4-2 ] then dpkg-statoverride --update --add sysuser root 4755 $i fi done + fi where 2.3.4-2 is to be replaced by the first version in which this statoverride was introduced. In this way, if the sysadmin later touches the statoverride, their changes will remain (for good or bad). It also means that it will fail miserably if the admin has added a statoverride before installing version 2.3.4-2. The previous code already would leave an existing statoverride alone; it would only add one if it did not already exist. -- - mdz
Bug#203650: Poor recommendation in dpkg-statoverride section
On Sat, 2 Aug 2003, Herbert Xu wrote: Adam Heath [EMAIL PROTECTED] wrote: Objection. There is no way to create any user in preinst as the tool to do so is not in an essential package. This is what pre-depends are for. A single pre-dependency is not enough. You will need to convert all of adduser's dependencies into pre-dependencies, and probably most of the things it depends on as well. No. adduser can still use normal depends. Pre-depends just means the dep'd on package has to be configured. And depends are for this exactly. You're confusing pre-depends and essentialness. You also need to ensure that adduser and anything that it depends on to function are always available at all times just like libc6. You're confusing pre-depends and essentialness.
Bug#203650: Poor recommendation in dpkg-statoverride section
On Mon, Aug 04, 2003 at 11:05:54AM -0500, Adam Heath wrote: On Sat, 2 Aug 2003, Herbert Xu wrote: A single pre-dependency is not enough. You will need to convert all of adduser's dependencies into pre-dependencies, and probably most of the things it depends on as well. No. adduser can still use normal depends. Pre-depends just means the dep'd on package has to be configured. And depends are for this exactly. You're confusing pre-depends and essentialness. I thought the same at first, but according to policy, pre-depends also allows the depended-upon package to be merely unpacked or half-configured provided that it has been fully configured at some point in the past. Is this not correct? -- Colin Watson [EMAIL PROTECTED]
Bug#203650: Poor recommendation in dpkg-statoverride section
On Mon, Aug 04, 2003 at 11:05:54AM -0500, Adam Heath wrote:
You also need to ensure that adduser and anything that it depends on to
function are always available at all times just like libc6.
You're confusing pre-depends and essentialness.
What about the case if adduser needs a new feature in useradd and
thus uses a versioned dependency on passwd. This means that the
new adduser can be unpacked before the new passwd is unpacked or
configured since it's only a plain old dependency.
As an unversioned pre-dependency is fulfilled as long as a
package was previously configured, this will allow packages declaring
pre-dependencies on adduser to run their preinsts even though
the new passwd is not yet available, rendering adduser useless.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#203650: Poor recommendation in dpkg-statoverride section
On Tue, 5 Aug 2003, Herbert Xu wrote: On Mon, Aug 04, 2003 at 11:05:54AM -0500, Adam Heath wrote: You also need to ensure that adduser and anything that it depends on to function are always available at all times just like libc6. You're confusing pre-depends and essentialness. What about the case if adduser needs a new feature in useradd and thus uses a versioned dependency on passwd. This means that the new adduser can be unpacked before the new passwd is unpacked or configured since it's only a plain old dependency. As an unversioned pre-dependency is fulfilled as long as a package was previously configured, this will allow packages declaring pre-dependencies on adduser to run their preinsts even though the new passwd is not yet available, rendering adduser useless. No. If foo pre-depends on bar, dpkg guarantees that bar is in a configured state, before it even considers doing anything with foo. And foo can only be in a configured state, if all it's normal deps(conflicts/etc) are sane. Please, get your dependency resolution straight. This is not rocket science.
Bug#203650: Poor recommendation in dpkg-statoverride section
On Thu, Jul 31, 2003 at 06:24:18PM +0100, Andrew Suffield wrote: for i in /usr/bin/foo /usr/sbin/bar do if ! dpkg-statoverride --list $i /dev/null then dpkg-statoverride --update --add sysuser root 4755 $i fi done The corresponding dpkg-statoverride --remove calls can then be made unconditionally when the package is purged. This means that the files are unpacked with whatever permissions were in the package, and are then modified during postinst. In addition, if the sysadmin removes the statoverride entry, the postinst will blindly add it back again later. Another possibility then is to do the following. Firstly, ensure that the default owner/group and permissions in the .deb are safe, and that if the package breaks because of them, it will do so in a safe way (the meaning of this will depend on the package). No-one expects an unconfigured package to necessarily work (with exceptions for essential packages, but we can ignore those here). Then change the line in the postinst: + if [ $1 = configure ] + then for i in /usr/bin/foo /usr/sbin/bar do - if ! dpkg-statoverride --list $i /dev/null + if [ dpkg --compare-versions $2 lt 2.3.4-2 ] then dpkg-statoverride --update --add sysuser root 4755 $i fi done + fi where 2.3.4-2 is to be replaced by the first version in which this statoverride was introduced. In this way, if the sysadmin later touches the statoverride, their changes will remain (for good or bad). Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, website: http://www.polya.uklinux.net/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Re: Bug#203650: Poor recommendation in dpkg-statoverride section
On Sat, 02 Aug 2003 09:59:13 +1000, Herbert Xu [EMAIL PROTECTED] said: Adam Heath [EMAIL PROTECTED] wrote: Objection. There is no way to create any user in preinst as the tool to do so is not in an essential package. This is what pre-depends are for. A single pre-dependency is not enough. You will need to convert all of adduser's dependencies into pre-dependencies, and probably most of the things it depends on as well. Do you really need that? Shouldn't a pre-depends kinda guarantee that the rpedepended package is installed and configured? If the package is installed and configured, all the uspstream dependencies should already be taken care of, no? manoj -- You who hate the Jews so, why did you adopt their religion? Friedrich Nietzsche, addressing anti-semitic Christians Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Bug#203650: Poor recommendation in dpkg-statoverride section
On Sat, Aug 02, 2003 at 09:59:13AM +1000, Herbert Xu wrote: Adam Heath [EMAIL PROTECTED] wrote: Objection. There is no way to create any user in preinst as the tool to do so is not in an essential package. This is what pre-depends are for. A single pre-dependency is not enough. You will need to convert all of adduser's dependencies into pre-dependencies, and probably most of the things it depends on as well. You also need to ensure that adduser and anything that it depends on to function are always available at all times just like libc6. Note that only a few packages will need these dependencies, unlike libc6. Specifically, these packages will be needed by a subset of the packages that currently Depends: adduser . Of those packages, only two are non-optional: ssh and pidentd. To fix that, the sshd and ??? accounts would need to be added to base-passwd. Policy-wise, there would be a rule that packages with priority standard or above cannot use the option to add needed users during installation, but must coordinate their needs with base-passwd. A transition mechanism for those two accounts would be needed too. Also, careful examination of the adduser implementation in woody indicates that the package really only needs its dependencies to be unpacked, at least to add system users and groups. The configure steps of adduser, passwd, and perl-base apparently only change things not affecting that particular operation. -- This message is hastily written, please ignore any unpleasant wordings, do not consider it a binding commitment, even if its phrasing may indicate so. Its contents may be deliberately or accidentally untrue. Trademarks and other things belong to their owners, if any.
Bug#203650: Poor recommendation in dpkg-statoverride section
On Sun, Aug 03, 2003 at 10:23:10PM +0200, Jakob Bohm wrote: On Sat, Aug 02, 2003 at 09:59:13AM +1000, Herbert Xu wrote: A single pre-dependency is not enough. You will need to convert all of adduser's dependencies into pre-dependencies, and probably most of the things it depends on as well. You also need to ensure that adduser and anything that it depends on to function are always available at all times just like libc6. Note that only a few packages will need these dependencies, unlike libc6. Specifically, these packages will be needed by a subset of the packages that currently Depends: adduser . Of those packages, only two are non-optional: ssh and pidentd. To fix that, the sshd and ??? accounts would need to be added to base-passwd. The ssh package does not contain any files owned by the sshd user, even after configuration, although it does arrange for /usr/bin/ssh-agent to be setgid ssh. Policy-wise, there would be a rule that packages with priority standard or above cannot use the option to add needed users during installation, but must coordinate their needs with base-passwd. I disagree (as base-passwd maintainer, although only for some months) with this principle; if it's necessary then I think we've made a design error. The intention for base-passwd is to reduce the number of entries in the globally allocated space, and thus the number of mandatory entries in /etc/passwd and /etc/group, not to increase them. In the long term I'm hoping that we can find a way to have even some of the current mandatory entries merely allocated in a registry somewhere in /usr/share/base-passwd which adduser can use to create those entries on demand, although clearly that would need delicate transitional handling. Furthermore, the priority standard line appears to be entirely arbitrary. I assume it's designed to reduce the number of entries that must be allocated in base-passwd. However, there is no reason why problems encountered by Priority: standard packages and above (provided they aren't Essential or in adduser's dependency chain) should not also be encountered by Priority: optional and Priority: extra packages. Therefore, in solving these problems for the latter class of packages we can also solve it for the former. Cheers, -- Colin Watson [EMAIL PROTECTED]
Bug#203650: Poor recommendation in dpkg-statoverride section
On Sun, Aug 03, 2003 at 10:23:10PM +0200, Jakob Bohm wrote:
Also, careful examination of the adduser implementation in
woody indicates that the package really only needs its
dependencies to be unpacked, at least to add system users and
groups. The configure steps of adduser, passwd, and perl-base
apparently only change things not affecting that particular
operation.
Can you really guarantee that this will be the case in future?
Remember when perl broke during the libdb upgrade?
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#203650: Poor recommendation in dpkg-statoverride section
Jakob Bohm wrote: Note that only a few packages will need these dependencies, unlike libc6. Specifically, these packages will be needed by a subset of the packages that currently Depends: adduser . You have to depend on adduser? Oops. Adjust your numers accordingly. :-) -- see shy jo pgpoFZkduq3j3.pgp Description: PGP signature
Bug#203650: Poor recommendation in dpkg-statoverride section
Andrew Suffield [EMAIL PROTECTED] wrote:
And appending this text to section 10.9:
If you want files in a package to be owned by a dynamically allocated
user or group, then you should create the user or group in preinst, so
that it is present when the package is unpacked.
Objection. There is no way to create any user in preinst as the tool
to do so is not in an essential package.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#203650: Poor recommendation in dpkg-statoverride section
Andrew Suffield wrote: Hold that thought. We hashed out a few ideas on IRC; more in a few days. Meanwhile, let's assume it will be solved... anything else? I missed that discussion, but the obvious approach in fakeroot is user autovivification (to bottow a term from perl) on chown. -- see shy jo pgpwkhfIYvLvs.pgp Description: PGP signature
Bug#203650: Poor recommendation in dpkg-statoverride section
On Fri, 1 Aug 2003, Herbert Xu wrote: Andrew Suffield [EMAIL PROTECTED] wrote: And appending this text to section 10.9: If you want files in a package to be owned by a dynamically allocated user or group, then you should create the user or group in preinst, so that it is present when the package is unpacked. Objection. There is no way to create any user in preinst as the tool to do so is not in an essential package. This is what pre-depends are for.
Bug#203650: Poor recommendation in dpkg-statoverride section
Adam Heath [EMAIL PROTECTED] wrote:
Objection. There is no way to create any user in preinst as the tool
to do so is not in an essential package.
This is what pre-depends are for.
A single pre-dependency is not enough. You will need to convert all
of adduser's dependencies into pre-dependencies, and probably most of
the things it depends on as well.
You also need to ensure that adduser and anything that it depends on to
function are always available at all times just like libc6.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#203650: Poor recommendation in dpkg-statoverride section
Package: debian-policy Here's the current text of the latter part of section 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. There is one type of situation, though, where calls to dpkg-statoverride would be needed in the maintainer scripts, and that involves packages which use dynamically allocated user or group ids. In such a situation, something like the following idiom can be very helpful in the package's postinst, where sysuser is a dynamically allocated id: for i in /usr/bin/foo /usr/sbin/bar do if ! dpkg-statoverride --list $i /dev/null then dpkg-statoverride --update --add sysuser root 4755 $i fi done The corresponding dpkg-statoverride --remove calls can then be made unconditionally when the package is purged. This means that the files are unpacked with whatever permissions were in the package, and are then modified during postinst. In addition, if the sysadmin removes the statoverride entry, the postinst will blindly add it back again later. So, let's break down what happens a bit: - dpkg unpacks the files, with their original permissions - postinst creates a user - postinst adds a statoverride to change the permissions The problem is that the user doesn't exist until after you unpack the files. Adding a statoverride here is a somewhat strange approach in its own right, ignoring such matters as the period between unpack and configure when permissions/owners are wrong. I suggest that this sequence would make more sense: - preinst creates a user - dpkg unpacks the files It's easier to understand and doesn't tread on the admin's toes as much. Note that dpkg stores users by name, not by uid. I propose replacing the above text entirely with this: Given the above, dpkg-statoverride is a tool for system administrators and is not needed in the maintainer scripts. And appending this text to section 10.9: If you want files in a package to be owned by a dynamically allocated user or group, then you should create the user or group in preinst, so that it is present when the package is unpacked. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | pgpQdk7Fuj5fy.pgp Description: PGP signature
Bug#203650: Poor recommendation in dpkg-statoverride section
On Thu, Jul 31, 2003 at 06:24:18PM +0100, Andrew Suffield wrote: So, let's break down what happens a bit: - dpkg unpacks the files, with their original permissions - postinst creates a user - postinst adds a statoverride to change the permissions The problem is that the user doesn't exist until after you unpack the files. Adding a statoverride here is a somewhat strange approach in its own right, ignoring such matters as the period between unpack and configure when permissions/owners are wrong. I suggest that this sequence would make more sense: - preinst creates a user - dpkg unpacks the files It's easier to understand and doesn't tread on the admin's toes as much. Note that dpkg stores users by name, not by uid. How should you ensure that the user in question exists on the system building the package? -- Colin Watson [EMAIL PROTECTED]
Bug#203650: Poor recommendation in dpkg-statoverride section
On Thu, 31 Jul 2003, Andrew Suffield wrote: Here's the current text of the latter part of section 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. There is one type of situation, though, where calls to dpkg-statoverride would be needed in the maintainer scripts, and that involves packages which use dynamically allocated user or group ids. In such a situation, something like the following idiom can be very helpful in the package's postinst, where sysuser is a dynamically allocated id: for i in /usr/bin/foo /usr/sbin/bar do if ! dpkg-statoverride --list $i /dev/null then dpkg-statoverride --update --add sysuser root 4755 $i fi done The corresponding dpkg-statoverride --remove calls can then be made unconditionally when the package is purged. Note that without --update, dpkg-statoverride will *not* change the perms of existing files on disk. This should be emphasized in any example given for usage. This means that the files are unpacked with whatever permissions were in the package, and are then modified during postinst. In addition, if the sysadmin removes the statoverride entry, the postinst will blindly add it back again later. So, let's break down what happens a bit: - dpkg unpacks the files, with their original permissions - postinst creates a user - postinst adds a statoverride to change the permissions The problem is that the user doesn't exist until after you unpack the files. Adding a statoverride here is a somewhat strange approach in its own right, ignoring such matters as the period between unpack and configure when permissions/owners are wrong. I suggest that this sequence would make more sense: - preinst creates a user - dpkg unpacks the files This implies that the deb would have the name of the dynamic user for the files. However, creating such a deb is problematic, as the build system will most likely not have the user. Extending adduser to tell faked(from fakeroot) to map dynamic users seems fugly to me, and doesn't handle the case when sudo(or just plain root) is used. However, perhaps having fakeroot divert adduser, and when adduser is then run under fakeroot, a fakeroot-specific version would be used, that would communicate with faked, would be better. There may still need to be a call to dpkg-statoverride, but it would be in the preinst.
Bug#203650: Poor recommendation in dpkg-statoverride section
On Thu, 2003-07-31 at 10:39, Colin Watson wrote: On Thu, Jul 31, 2003 at 06:24:18PM +0100, Andrew Suffield wrote: So, let's break down what happens a bit: - dpkg unpacks the files, with their original permissions - postinst creates a user - postinst adds a statoverride to change the permissions The problem is that the user doesn't exist until after you unpack the files. Adding a statoverride here is a somewhat strange approach in its own right, ignoring such matters as the period between unpack and configure when permissions/owners are wrong. I suggest that this sequence would make more sense: - preinst creates a user - dpkg unpacks the files It's easier to understand and doesn't tread on the admin's toes as much. Note that dpkg stores users by name, not by uid. How should you ensure that the user in question exists on the system building the package? If somebody were willing to put a fair bit of effort into this, I think the following would work: If a package should contain files owned by the user grinch, then debian/rules must execute the command fakeroot-createuser grinch This command first checks whether a user grinch already exists; if so, it does nothing. If not, it uses some private communication channel to tell fakeroot to pretend this user exists. If this fails, then it is not running under fakeroot; it prints a message something like the following: To build this package, you must either create a user grinch or do the build under fakeroot. As the error message indicates, this should allow the package to be built either by creating the user and building the package as root, or by building the package using fakeroot. Of course, this is a lot of effort to avoid temporarily having files with the wrong owner/permissions during installation. Carl Witty
Bug#203650: Poor recommendation in dpkg-statoverride section
On Thu, Jul 31, 2003 at 06:39:38PM +0100, Colin Watson wrote: On Thu, Jul 31, 2003 at 06:24:18PM +0100, Andrew Suffield wrote: So, let's break down what happens a bit: - dpkg unpacks the files, with their original permissions - postinst creates a user - postinst adds a statoverride to change the permissions The problem is that the user doesn't exist until after you unpack the files. Adding a statoverride here is a somewhat strange approach in its own right, ignoring such matters as the period between unpack and configure when permissions/owners are wrong. I suggest that this sequence would make more sense: - preinst creates a user - dpkg unpacks the files It's easier to understand and doesn't tread on the admin's toes as much. Note that dpkg stores users by name, not by uid. How should you ensure that the user in question exists on the system building the package? Hold that thought. We hashed out a few ideas on IRC; more in a few days. Meanwhile, let's assume it will be solved... anything else? -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | pgpbtY23161n7.pgp Description: PGP signature
Bug#203650: Poor recommendation in dpkg-statoverride section
On Thu, Jul 31, 2003 at 01:16:35PM -0500, Adam Heath wrote: However, perhaps having fakeroot divert adduser, and when adduser is then run under fakeroot, a fakeroot-specific version would be used, that would communicate with faked, would be better. That's problematic too. You imply that build scripts should call adduser; and I don't think that merely building a package with real root privileges should modify the state of my system in major ways like adding new users. -- Colin Watson [EMAIL PROTECTED]
