This queue is for tickets about the CPAN CPAN distribution.

Report information
The Basics

Nobody in particular
jpl [...]

(no value)
Broken in:
(no value)
Fixed in:
(no value)

CC: jpl <>
Subject: Group sharing a perl installation
Date: Tue, 21 Jun 2011 14:40:33 -0400
From: "John P. Linderman (jpl)" <>
For a bit of extra background on what's going on, please see
Show quoted text
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.

Show quoted text
  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

Show quoted text
  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
-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 using

        $packagedir = File::Temp::tempdir(
                                          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 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 also preserves it.  One possibility would be to have 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

This service runs on Request Tracker, is sponsored by The Perl Foundation, and maintained by Best Practical Solutions.

Please report any issues with to