Gateway file creation does not inherit the destination directory's POSIX ACL and GID

Gateway file creation does not inherit the destination directory's POSIX ACL and GID

Description

When creating objects through PUT, COPY, or multipart upload completion, Gateway first creates a temporary file under .sys/tmp or .sys/uploads, then renames it to the destination path.

The file inherits attributes from the temporary directory at creation time. Rename does not reapply the destination directory's default ACL or GID inheritance rules. Consequently, the resulting file may violate the destination directory's permission policy, potentially granting broader access than intended.

This issue concerns JuiceFS POSIX ACLs, not S3 object ACLs.

Version checked

Main branch commit: 482a0c4e4e21a05f3c9bc2f5369fe64088b5a7fc.

This is an existing issue on main and does not depend on #7479.

Reproduction

1. Enable JuiceFS ACL support.
2. Set the destination directory's GID to 2468 and enable setgid.
3. Configure its default ACL so that newly created regular files should have mode 0600.
4. Use Gateway to:
   • PUT a new object;
   • COPY an object to a new destination in that directory;
   • Complete a multipart upload targeting a new object in that directory.
5. Compare each resulting file's mode, GID, and access ACL with a file created directly in the same directory.

With default temporary-directory permissions and Gateway creating files as GID 0, the results were:

Creation method	File mode	GID	Access ACL
Direct creation in the destination directory	0600	2468	Derived from the destination directory's default ACL
Gateway PUT	0644	0	Does not inherit the destination directory's default ACL
Gateway COPY	0644	0	Does not inherit the destination directory's default ACL
Gateway multipart upload completion	0644	0	Does not inherit the destination directory's default ACL

The issue also reproduces with a default ACL containing a named user: direct creation produces mode 0640, while Gateway produces 0644.

The actual incorrect permissions depend on the temporary directory's attributes, Gateway's identity, and umask; they are not necessarily always 0644.

Expected behavior

New files created through Gateway should follow the destination directory's default ACL and setgid/GID inheritance rules, consistent with direct file creation in that directory.

Root cause

The relevant paths are in pkg/gateway/gateway.go:

• putObject: creates and writes a temporary file, then renames it to the destination.
• CopyObject: copies through a temporary file, then renames it.
• CompleteMultipartUpload: assembles a complete file under the uploads directory, then renames it.

Metadata creation applies inheritance using the parent directory at creation time. Rename preserves the inode's existing permission attributes rather than recalculating them from its new parent.

Impact

• New files may have broader permissions than the destination directory's policy allows.
• Named-user and group permissions specified by the destination directory's default ACL may not be applied.
• Files created under a setgid directory may belong to the wrong group.

Ordinary directory-object PUT on main creates directories directly at the destination. The same issue was not observed on that path.

Verification scope

Reproduced on Linux and macOS using Gateway ObjectLayer method-level tests with ACL-enabled memkv metadata.

S3 HTTP end-to-end tests and runtime verification against Redis and SQL backends have not yet been performed.