Maven Site Plugin
  1. Maven Site Plugin
  2. MSITE-330

Wagon nukes the permission bits of uploaded files.

    Details

    • Type: Bug Bug
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: site:deploy
    • Labels:
      None
    • Number of attachments :
      0

      Description

      Uploading a site using wagon might nuke permission bits of e.g. CGI scripts thus making these unavailable.

      For Apache webserver, a CGI script can have the permission bit set and is then executed. This is e.g. used for the "download.cgi" script on many Apache project sites.

      The wagon uploader (at least ssh and ssh-external) unconditionally change the permissions of all files to be 664. Which kills the execution bits. Which is bad (TM).

        Issue Links

          Activity

          Hide
          Carlos Sanchez added a comment -

          Maybe wagon should use <filePermissions> only for new files
          http://maven.apache.org/plugins/maven-deploy-plugin/examples/deploy-ssh-external.html

          Show
          Carlos Sanchez added a comment - Maybe wagon should use <filePermissions> only for new files http://maven.apache.org/plugins/maven-deploy-plugin/examples/deploy-ssh-external.html
          Hide
          Henning Schmiedehausen added a comment -

          Any news on this issue? This is now open for two months.

          Show
          Henning Schmiedehausen added a comment - Any news on this issue? This is now open for two months.
          Hide
          Carlos Sanchez added a comment -

          without patches it could be sitting here for long time until somebody volunteers

          Show
          Carlos Sanchez added a comment - without patches it could be sitting here for long time until somebody volunteers
          Hide
          Brett Porter added a comment -

          this is a result of chmod -Rf in the site plugin - wagon is doing the right thing. It keeps permissions on existing files copied individually.

          Show
          Brett Porter added a comment - this is a result of chmod -Rf in the site plugin - wagon is doing the right thing. It keeps permissions on existing files copied individually.
          Hide
          Brett Porter added a comment -

          in addition, the site plugin really shouldn't execute this - it should rely on the wagon to set them correctly. We can address issues in wagon where putDirectory doesn't set the permissions correctly. Simply removing the lines is probably the fix here.

          Show
          Brett Porter added a comment - in addition, the site plugin really shouldn't execute this - it should rely on the wagon to set them correctly. We can address issues in wagon where putDirectory doesn't set the permissions correctly. Simply removing the lines is probably the fix here.
          Hide
          Dennis Lundberg added a comment -

          Currently the site-plugin does this:

          chmod -Rf g+w,a+rX

          on the deployment directory. So it shoudn't remove any bits - just add them.

          Show
          Dennis Lundberg added a comment - Currently the site-plugin does this: chmod -Rf g+w,a+rX on the deployment directory. So it shoudn't remove any bits - just add them.
          Hide
          Dennis Lundberg added a comment -

          Perhaps you have a server section in your settings.xml that overrides the file permissions?
          Something like this:

              <server>
                <username>myUserId</username>
                <id>apache.website</id>
                <directoryPermissions>775</directoryPermissions>
                <filePermissions>664</filePermissions>
              </server>
          
          Show
          Dennis Lundberg added a comment - Perhaps you have a server section in your settings.xml that overrides the file permissions? Something like this: <server> <username> myUserId </username> <id> apache.website </id> <directoryPermissions> 775 </directoryPermissions> <filePermissions> 664 </filePermissions> </server>
          Hide
          Paul Spencer added a comment -

          1) The command "chmod -Rf g+w,a+rX" fails on HP-UX servers because "f", which is for silent output, is not an option.

          2) I would prefer the file permissions, directory permissions, and chmod options be in the <distributionManagement><site> tag since the values are specific to the server. Each user should not have different values for the tags.

          pom.xml
          <project>
            ...
            <distributionManagement>
              <site>
                <id>projects.foo.com</id>
                  <name>Foo.Com Project Site</name>
                  <url>scp://projectsfoo.com/${project.artifactId}/${project.version}</url>
                  <directoryPermissions>775</directoryPermissions>
                  <filePermissions>664</filePermissions>
                  <chmodSilentOption/> <!-- Defaults to "f" -->
                  <chmodRecursiveOption/> <!-- Defaults to "R" -->
                </site>
              </distributionManagement>
          </project>
          
          Show
          Paul Spencer added a comment - 1) The command "chmod -Rf g+w,a+rX" fails on HP-UX servers because "f", which is for silent output, is not an option. 2) I would prefer the file permissions, directory permissions, and chmod options be in the <distributionManagement><site> tag since the values are specific to the server. Each user should not have different values for the tags. pom.xml <project> ... <distributionManagement> <site> <id> projects.foo.com </id> <name> Foo.Com Project Site </name> <url> scp://projectsfoo.com/${project.artifactId}/${project.version} </url> <directoryPermissions> 775 </directoryPermissions> <filePermissions> 664 </filePermissions> <chmodSilentOption/> <!-- Defaults to "f" --> <chmodRecursiveOption/> <!-- Defaults to "R" --> </site> </distributionManagement> </project>
          Hide
          Lukas Theussl added a comment -

          Command-line zip/unzip preserves permissions and remotely the command line unzip is used. So the problem is really with wagon, the x bit gets lost when zipping up the site. The rest is just a question of setting up the server and umask settings.

          Show
          Lukas Theussl added a comment - Command-line zip/unzip preserves permissions and remotely the command line unzip is used. So the problem is really with wagon, the x bit gets lost when zipping up the site. The rest is just a question of setting up the server and umask settings.

            People

            • Assignee:
              Unassigned
              Reporter:
              Henning Schmiedehausen
            • Votes:
              2 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: