Bug #69001 for CPAN: Group sharing a perl installation

For a bit of extra background on what's going on, please see http://www.perlmonks.org/?node_id=910367 What's happening is a group of trustworthy users want to maintain their own installation of perl on a machine where they lack super-user privileges. So we got a "perl" group created, with all the trusted users in that group, and I did an install of perl (5.14.1) under a directory (/fs/perl) group-owned by the "perl" group. On the system in question, group ownership of newly created files and directories is determined by the group and permissions of the directory in which the file/directory is created (not, as is sometimes the case, by a file-system-wide setting). If the containing directory has the setgroupid bit (02000) on, and is group-owned by a group of which the creator is a member, then the file/directory is group-owned by the group (and directories inherit the setgroupid bit, so group ownership propagates down). Otherwise, the file/directory is group-owned by the primary group of the creator, with no setgroupid bit set. The file/directory is always owned by the creator. So, by making sure all the trusted users have a umask of 02 (not 022, so group write permission is on by default), and by making the base directory group-owned by "perl" and mode 02775, the basic install works just fine. The link above had a good suggestion for setting up a common CPAN directory in /fs/perl/.cpan, and HOME=/fs/perl cpan upgrade did a creditable job of bringing everything up to date. I then asked a different user in the group to try a CPAN install, and, except for a few "chmod 666 failed" warnings, then installation went well. I did another upgrade today (nice that modules mutate fast enough to make that a non-trivial test after a couple days :-), and it worked, but there were more warnings about permission failures. So I took a closer look. ls -ld /fs/perl/.cpan/build drwxrwsr-x 80 jpl perl 8192 Jun 21 13:11 /fs/perl/.cpan/build The build directory has the desired properties, but ls -ld /fs/perl/.cpan/build/TOM* drwxrwxr-x 3 jpl perl 98 Jun 21 13:31 /fs/perl/.cpan/build/TOMC-k6xt_q -rw-rw-r-- 1 jpl perl 1278 Jun 21 13:11 /fs/perl/.cpan/build/TOMC-k6xt_q.yml ls -l /fs/perl/.cpan/build/TOMC-k6xt_q total 40 -rw-rw-r-- 1 jpl perl 6470 Jun 21 13:11 Edit.pm -rw-rw-r-- 1 jpl jpl 398 Jun 21 13:11 MYMETA.yml -rw-r--r-- 1 jpl jpl 22723 Jun 21 13:11 Makefile -rw-rw-r-- 1 jpl jpl 248 Jun 21 13:11 Makefile.PL drwxrwxr-x 8 jpl jpl 72 Jun 21 13:11 blib -rw-rw-r-- 1 jpl jpl 0 Jun 21 13:11 pm_to_blib directories being created under it lack the setgroupid bit, and (most) files and directories thereunder are ending up group-owned by the installer. I tracked this down to CPAN::Distribution.pm using $packagedir = File::Temp::tempdir( "$tdir_base-XXXXXX", DIR => $builddir, CLEANUP => 0, ); chmod 0777 &~ umask, $packagedir; # may fail to create the directory under .cpan/build. File::Temp::tempdir itself does # Open the temp directory if (mkdir( $path, 0700)) { # in case of odd umask chmod(0700, $path); return undef, $path; } to make a (secure) temporary directory. The "problem" is that perl's chmod(), unlike (my) /bin/chmod, does not preserve the setgroupid bit on directories. So File::Temp::tempdir is turning the bit off, and Distribution.pm is not turning it back on. This results in "breaking" the "group ownership hierarchy" that makes it possible for different users in the same group to get along. I'm not sure if you regard this as a "bug", or, if you do, what to do to fix it. There would be no point in preserving the setgroupid bit in File::Temp::tempdir unless CPAN::Distribution.pm also preserves it. One possibility would be to have CPAN::Distribution.pm do a "trial" mkdir, and see if the setgid bit comes on unbidden. That would be a pretty fair indication that it should be turned back on after tempdir() does it's thing. Another possibility would be to add yet another CPAN configuration option for bits to be set on for directory creation. I'm pretty impressed that the shared perl installation gets along as well as it does. The usual model is for installations to be managed by a single user (often root), so it's not surprising that things aren't perfect for groups rather than individuals. -- jpl