dynamic users (Re: dpkg-statoverride (Re: RFS: mediatomb -- open source (GPL) UPnP MediaServer with a web interface))
On Fri, Nov 09, 2007 at 02:26:42PM -0500, Andres Mejia wrote:
> On Nov 9, 2007 5:24 AM, Michael Biebl <biebl@teco.edu> wrote:
> >
> > Am Donnerstag, den 08.11.2007, 20:31 -0500 schrieb Justin Pryzby:
> > > On Fri, Nov 09, 2007 at 10:35:00AM +0930, Paul Wise wrote:
> > > > On Nov 9, 2007 9:43 AM, Justin Pryzby <jpryzby+d@quoininc.com> wrote:
> > > >
> > > > > On Fri, Nov 09, 2007 at 09:35:05AM +0930, Paul Wise wrote:
> > > > > > postinst should use dpkg-statoverride instead of chown
> > > > > Really? I thought this was an administrator's tool, and the postinst
> > > > > should do something like
> > > >
> > > > I guess I meant "chowning blindly" instead of "chown".
> > > >
> > > > I do note that a few postinst files in my /var/lib/dpkg/info/ use
> > > > dpkg-statoverride rather than chown.
> > > >
> > > > I guess I should reread devref/policy.
> > > Policy mentions this in 10.9.1; it appears that it can be correct to
> > > do either dpkg-statoverride --update or use chown directly, as long as
> > > it's conditional on does dpkg-statoverride -l $f >/dev/null.
> > >
> > > I note that using chown doesn't add the file to the override data,
> > > which I argue is a good thing due to no ambiguity about who put it
> > > there.
> >
> > I had the same issue myself, some days ago. I wasn't sure if using chown
> > or dpkg-statoverride in postinst was the correct way.
> > You argue for not using dpkg-statoverride, policy seems to recommend it
> > though. Asking on #debian-devel, the answers I got were, to use
> > dpkg-statoverride unless I have a very good reason not to.
> > I think one disadvantage of using chown in postinst is, that you have a
> > time frame between unpack and postinst, where the binary has the wrong
> > the permissions. With dpkg-statoverride, dpkg will take care that the
> > binary has always the correct permissions.
> > So this is a big advantage of using dpkg-statoverride.
> > Admittedly it would be nice, if policy was more precise in that matter.
>
> Thanks for the suggestions. I went ahead and made the changes. Here's
> the changelog for 0.10.0-5 of this package.
>
> [ Andres Mejia ]
> * Using deluser and delgroup commands to remove meditomb user and group.
> * Removed dependency on passwd.
> * Added --disabled-{login,password} for adduser in preinst.
BTW did you know that adduser --system adds a user *and* a group? For
system users only. {,} is a bashism of course.
Why do you remove the user/group? I think the suggestion is to leave
dynamic system ID's to avoid them being recreated with a different
(system) user which now has access to some stray files leftover from a
different package. If the admin wants to get rid of them, they can do
find / -user $u -o -group $u -ls at their convenience, or look in
obvious places or decide it's not worth the effort.
I think if you do use deluser, it should be in "purge" and not
"remove".
Justin
Reply to: