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.



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