Add permissions/ownership to files/folders from config-file

[rikvdh]

No description provided.

[xor-gate]

This must be left to the package builder with postinst. Read https://www.debian.org/doc/debian-policy/ch-files.html#s-permissions-owners

Only we must force:

Files should be owned by root:root, and made writable only by the owner and universally readable (and executable, if appropriate), that is mode 644 or 755.

Directories should be mode 755 or (for group-writability) mode 2775. The ownership of the directory should be consistent with its mode: if a directory is mode 2775, it should be owned by the group that needs write access to it. [98]

Control information files should be owned by root:root and either mode 644 (for most files) or mode 755 (for executables such as maintainer scripts).

Setuid and setgid executables should be mode 4755 or 2755 respectively, and owned by the appropriate user or group. They should not be made unreadable (modes like 4711 or 2711 or even 4111); doing so achieves no extra security, because anyone can find the binary in the freely available Debian package; it is merely inconvenient. For the same reason you should not restrict read or execute permissions on non-set-id executables.

[jeremyvisser]

I’m reading the same text quoted above, and I agree with the sentiment that package–managed files should generally be owned by root:root and world–readable.

However, I don’t think it’s a correct interpretation that all ownership/permissions must be set in postinst. In fact, all of the references to postinst in the linked document appear to fall under these broad categories:

• Where a dynamic UID/GID is needed (e.g. postinst invokes adduser, and sets ownership accordingly)
• Directory permission changes
• Special files (named pipes, device files)

Meanwhile, the following situations are implied to use the tarball permissions:

• Statically allocated UID/GID (allocated by Debian committee, which is likely N/A for typical uses of this library)
• Specific setuid/setgid requirements (e.g. mode 2775)

The document also talks about the dpkg-statoverride tool, which is intended for the user to override the permissions ordinarily set by the package tarball (not intended for postinst use).

So I think it’s correct to say that typically most ownership should be root:root, and permissions be 0755 or 0644, with the occasional setuid/setgid thrown in where needed.

But I don’t think it’s correct to say this should be implemented in the postinst. It’s even possible doing so would erroneously interfere with dpkg-statoverride (though I’d guess not a common case).

As for my use case, I’m building a package as a non–root user, and I’d like the resulting package files to have normal root:root ownership. However, the resulting package files are owned by the non–root user. I don’t think it’s correct to fix this in postinst, and I don’t think it’s correct to build the package as root in this situation.

I’m aware of the existence of fakeroot which is intended to help with programs that make similar assumptions, but at least on macOS doesn’t work for me. Perhaps this is because it works by overriding libc functions, but Go doesn’t use libc? And Windows is another completely different story.

The archive/tar package in the Go standard library actually handles this well, where tar.Writer has AddFS(fsys fs.FS) error, which uses interface fs.FS, which is very flexible. For example, it can work against embed filesystems.

Meanwhile, the internal/targz package assumes real file paths, and uses the actual (*os.File).Stat() output to set the permissions, but immediately afterwards passes to tar.FileInfoHeader(info fs.FileInfo, link string) which accepts an interface.

I understand wanting to avoid exposing too many functions/args/options, but I think setting the ownership/permissions is justified. Even a (*TarGzip).AddFS(fsys fs.FS) that simply calls (*tar.Writer).AddFS(fsys) would be useful here.

Since tarballs aren’t seekable, we can’t practically implement a SetOwner() or SetMode() for a file after it’s been added, so whatever we end up with would be an alternative to AddFile().

If I were to work on a pull request that adds something along these lines, would you be happy to consider that? I’m new to this project so I’d be happy to accept any feedback.

[jeremyvisser]

After having written far too much above, I realised my particular case was already solved in b54eb58. I hadn’t noticed, as that commit isn’t present in tag v1.0.0.

While I still think there are use cases for non–root:root ownership, for my specific case, the existing code is good enough. :-)

[xor-gate]

Sorry for my late reply, i have read your issue multiple times and postponed the response. Past weeks I created a debian package from macOS/FreeBSD and did some package contents list on debian with dpkg, it showed root:root for the files even created as non-root user. So not sure why you have non-root:root ownership in the package.

I was using @latest during go install. That is why it worked for me.