Building site fails with group-only permissions #2749

Closed
schachmat opened this Issue Nov 29, 2016 · 6 comments

Comments

Projects
None yet
2 participants
@schachmat

Heyho,

I'm using hugo 0.16-2 from the debian jessie repositories on a Debian jessie installation. For our website destination directory (the one passed with -d) we have owner wwwowner and group wwwgroup. Since this directory is NFS mounted on another multiuser-host, the permissions on this directory should be 0770 with the sgid-bit set. Now when running hugo it tries to chmod that directory to 0755 every time and fails since the wwwowner is a system-user not used by the people building the site. Those peoples useraccounts are all part of the wwwgroup group and therefore can do anything inside the destination directory. However they cannot change the destination directory itself so hugo fails, aborts and does not create the site. Is there any reasoning within this behaviour? Could it be changed to just print a warning if hugo fails to chmod and utimensat(2) the destination directory?

The setup I described worked with 0.12, so this is at least a regression.

Let me know if you need more information.

@moorereason

This comment has been minimized.

Show comment
Hide comment
@moorereason

moorereason Nov 29, 2016

Member

umask(1) is your friend.

Member

moorereason commented Nov 29, 2016

umask(1) is your friend.

@schachmat

This comment has been minimized.

Show comment
Hide comment
@schachmat

schachmat Nov 29, 2016

That will probably not help, because the used fsync code calls chmod directly: https://github.com/spf13/fsync/blob/master/fsync.go#L213

That will probably not help, because the used fsync code calls chmod directly: https://github.com/spf13/fsync/blob/master/fsync.go#L213

@moorereason

This comment has been minimized.

Show comment
Hide comment
@moorereason

moorereason Nov 29, 2016

Member

Hmm...

  1. Hugo creates the publishdir without respecting umask.
  2. Hugo respects umask when generating content inside publishdir.
  3. When copying files from staticdir into publishdir, hugo (or fsync?) Chmod's the new file to match the original file's perms.

One option: see this commit to golang. They create a file, check perms to derive umask bits, and then use the necessary perms in calls to Chmod. @schachmat, would this work in your scenario? It seems a little hackish.

Other option would be to add yet another config option to set umask within Hugo.

Member

moorereason commented Nov 29, 2016

Hmm...

  1. Hugo creates the publishdir without respecting umask.
  2. Hugo respects umask when generating content inside publishdir.
  3. When copying files from staticdir into publishdir, hugo (or fsync?) Chmod's the new file to match the original file's perms.

One option: see this commit to golang. They create a file, check perms to derive umask bits, and then use the necessary perms in calls to Chmod. @schachmat, would this work in your scenario? It seems a little hackish.

Other option would be to add yet another config option to set umask within Hugo.

@schachmat

This comment has been minimized.

Show comment
Hide comment
@schachmat

schachmat Nov 30, 2016

I managed to get it working by doing it the other way around: Instead of preventing the change on the publish-dir I set the permissions of the static/ directory in my source-dir to the same permissions the publish-dir must have (and already has). Only then hugo/fsync won't call Chmod when copying the static content.

I also had to set noTimes: true in the site config because otherwise hugo would try to update the timestamp on the publish-dir, which of course also failed due to missing permissions.

Now I don't know if you want to add some documentation regarding this special case or not. In case you want, feel free to use this issue to track progress, otherwise just close it.

I managed to get it working by doing it the other way around: Instead of preventing the change on the publish-dir I set the permissions of the static/ directory in my source-dir to the same permissions the publish-dir must have (and already has). Only then hugo/fsync won't call Chmod when copying the static content.

I also had to set noTimes: true in the site config because otherwise hugo would try to update the timestamp on the publish-dir, which of course also failed due to missing permissions.

Now I don't know if you want to add some documentation regarding this special case or not. In case you want, feel free to use this issue to track progress, otherwise just close it.

moorereason added a commit to moorereason/hugo that referenced this issue Nov 30, 2016

@moorereason

This comment has been minimized.

Show comment
Hide comment
@moorereason

moorereason Nov 30, 2016

Member

I don't like the fact that hugo doesn't honor the system umask, but the main fix is needed upstream in fsync. So, I've submitted companion PRs to fsync and hugo to fix it.

Member

moorereason commented Nov 30, 2016

I don't like the fact that hugo doesn't honor the system umask, but the main fix is needed upstream in fsync. So, I've submitted companion PRs to fsync and hugo to fix it.

@moorereason moorereason added this to the v0.18 milestone Nov 30, 2016

@bep bep closed this in #2751 Nov 30, 2016

bep added a commit that referenced this issue Nov 30, 2016

commands: Add noChmod option to disable perm sync
Includes updates to docs.

Fixes #2749
@schachmat

This comment has been minimized.

Show comment
Hide comment
@schachmat

schachmat Nov 30, 2016

Nice, thanks for the general fix.

Nice, thanks for the general fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment