Re: group id of newly created nodes
On Fri, Apr 26, 2002 at 02:56:38PM +0200, Marcus Brinkmann wrote:
> (please CC me on replies)
> we have found an interesting problem in Debian package scripts. This is
> related to the behaviour of the Hurd and BSD to create new files with the
> gid of the parent directory, rather than the process. And sgid flag on
> directories is simply ignored. POSIX allows that.
It seems this is default on FreeBSD, also.
> For example, if you build a package as root which is unpacked as user joe,
> the files in the package will have a group of joe. You can imagine that
> this is not a good thing to have. It should be the same on the Hurd as on
> BSD, but I have no BSD around to check.
It looks like it acts the same.
> So I thought I would just give you a heads up on this issue, because it
> really puzzled me, and maybe you want to check if your builds are all fine.
> Candidates are dpkg, base-files, and debianutils because their debian/rules
> commands are not careful enough to explicitely set the group to root.
Then that's a bug in the rules of those packages. It's sloppy, and needs
to be fixed.
> I don't know if you have fakeroot for BSD. But it should even show up in a
> fakeroot build.
I have fakeroot. I haven't checked what it does yet.
> If you unpack and build as root, you will also want to know about bug report
This is perfectly normal behaviour for tar. dpkg-source should either
invoke tar with --no-same-owner, or clean up itself.
> I hope this is helpful. If you don't have this problem, congratulations and
> just ignore this mail :) If you have this problem, you might need to fix
> those debian/rules files. For the Hurd, we definitely have this problem but
> we might change the default to be like Linux in this regard, so I am not
> sure if we will continue to have it. If we do, we need to fix those
> rules files, too, and we might coordinate our efforts.
Thanks for the heads-up. I believe the scripts should be fixed,
regardless. They don't handle that behaviour, and they don't fail
either. That's a bug, because this can happen even on Linux. ext2fs has
the grpid or bsdgroups option that causes the same behaviour, according
to the man page for mount. (I've never used it.) What happens if someone
used it? Undefined behaviour?
That mount option might be useful for finding this particular packaging
problem. Someone could put an autobuilder on a filesystem like that, then
run a script that scans packages for the group id the build was run
under. Wouldn't be hard, dpkg -c foo.deb | grep sbuild might work.
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com