pkgsrc-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pkg/44048: Prebuilt mailman pkg enforces uid/gid.



The following reply was made to PR pkg/44048; it has been noted by GNATS.

From: Lars-Johan Liman <liman%cafax.se@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: pkg-manager%NetBSD.org@localhost, gnats-admin%NetBSD.org@localhost, 
pkgsrc-bugs%NetBSD.org@localhost
Subject: Re: pkg/44048: Prebuilt mailman pkg enforces uid/gid.
Date: Sat, 06 Nov 2010 21:06:05 +0100

 On Fri, Nov 05, 2010 at 04:20:00PM +0000, liman%cafax.se@localhost wrote:
 >>     It would be appreciated if the +INSTALL script took note of
 >>     any existing user/group "mailman" and used the already exising
 >>     UID/GID for the installation.
 
 joerg%britannica.bec.de@localhost:
 >  The problem here is that the uid/gid is hard-coded in mailman itself.
 
 Err... I hope I misunderstand you. AFAICT it is not hardcoded in mailman
 itself.
 
 I'm talking about the user _NUMBER_ and the group _NUMBER_ that the
 +INSTALL tries to enfoce during install.
 
 If you look at the pre-compiled package, you'll find that the +INSTALL
 fill wants to install a user with the username "mailman" and with UID
 (number) 1002, and a group with the groupname "mailman" and with GID
 (number) 1001.
 
 
 netbsd:pkgbin/mailman> egrep -w '100[12]' ./+*
 ./+INSTALL:# GROUP: mailman:1001
 ./+INSTALL:# USER: mailman:mailman:1002:Mailman user:/nonexistent:/bin/sh
 
 
 If you look further down the binary packages you will only find matches
 in PDF files, PS files, a module with translated strings (where it
 matches line numbers) and in test messages.
 
 
 mail:pkgbin/mailman> find . -type f | xargs egrep -l  -w '100[12]'
 /+INSTALL               <--- This is the offending one from above.
 ./lib/mailman/messages/sv/LC_MESSAGES/mailman.po
 ./lib/mailman/tests/bounces/simple_28.txt
 ./share/doc/mailman/mailman-admin.pdf
 ./share/doc/mailman/mailman-install.pdf
 ./share/doc/mailman/mailman-member-es.pdf
 ./share/doc/mailman/mailman-member-es.ps
 ./share/doc/mailman/mailman-member.pdf
 
 
 If you grep for '100[12]' in the _source_code_ (as distributed by GNU),
 you will, again, only find matches in roughly the same files. It doesn't
 match anywhere in the active code, and hence, it's not hardcoded in the
 mailman code.
 
 
 netbsd:src/mailman-2.1.12> find . -type f | xargs egrep -l  '100[12]'
 ./doc/mailman-admin.pdf
 ./doc/mailman-install.pdf
 ./doc/mailman-member-es.pdf
 ./doc/mailman-member-es.ps
 ./doc/mailman-member.pdf
 ./doc/mailman-member.ps
 ./messages/sv/LC_MESSAGES/mailman.po
 ./tests/bounces/dsn_08.txt
 ./tests/bounces/simple_08.txt
 ./tests/bounces/simple_28.txt
 ./tests/bounces/simple_31.txt
 ./tests/msgs/bad_01.txt
 
 
 There is, however, a default user _NAME_ "mailman" and a default group
 _NAME_ "mailman" hardcoded as default in the code, but that's not what
 I'm talking about. I can live with having a user called "mailman" on my
 system, as long as no one tries to enforce a specific UID (number) for
 it. Furthermore, it is even possible to change that default username at
 compile time:
 
 
 netbsd:src/mailman-2.1.12> ./configure --help | egrep 'with-(user|group)'
   --with-username      specify a user name other than \"mailman\"
   --with-groupname     specify a group name other than \"mailman\"
 
 
 ... but I'm not resquesting that you change that default name in the
 precompiled package.
 
 All I request is that the code in the +INSTALL file be changed so that
 it doesn't enforce the UID (number) 1002 and the GID (number) 1001,
 especially since that may not match on a system that one is upgrading,
 as older versions of the binary package seem to have had different
 numbers, and a "conflict" arises.
 
 I believe someome (robot? pkg-maintainer?) made an install from source
 (where I assume a suitably agnostic "useradd" command was issued as part
 of the installation procdure), and the UID and GID that happened to be
 created on _that_ specific machine were "picked up" and hardcoded it
 into +INSTALL, thus creating the situation above. That is unfortunate.
 It must be possible to "tell" +INSTALL to be agnostic about the numbers.
 
                                Best regards,
                                  /Liman
 


Home | Main Index | Thread Index | Old Index