Aptly disrespects umask

[Hawk777]

Aptly creates files and directories in db and pool which do not respect my umask.

Detailed Description

$ cat .aptly.conf 
{
  "rootDir": "/home/me/aptly"
}
$ umask
0002
$ aptly_1.5.0_linux_amd64/aptly repo create foo

Local repo [foo] successfully added.
You can run 'aptly repo add foo ...' to add packages to repository.
$ ls -l /home/me/aptly
total 0
drwxr-xr-x 1 me me 78 Jul 21 08:43 db

The db directory has permission 0755. Since my umask is 0002, it should have 0775.

Context

If Aptly obeyed its umask, I could use umask 0002 and an SGID directory to allow all users in a group to collaborate on maintaining a single repository.

Possible Implementation

Pass 0777 to the directory creation syscall and 0666 to the file creation syscall, like most software does, rather than, I assume, 0755 and 0644.

Your Environment

AMD64 Ubuntu Jammy, both using the packaged 1.4.0 and also the 1.5.0 from the GitHub release.

[r4co0n]

If Aptly obeyed its umask, [...]
[...]
The db directory has permission 0755. Since my umask is 0002, it should have 0775.

I don't know what you mean by "obeying" umask. Users and the programs they run have "always" been free to write files with permissions they feel are appropriate, the umask is applied afterwards and removes some of those permissions - If they were there. I think umask is not intended to work as you describe, and i suppose it would be rather stupid to write out all files with 777 minus umask or something like that.

My bookworm umask(2) says:

       The umask is used by open(2), mkdir(2), and other system calls that create files to modify the  per‐
       missions  placed  on newly created files or directories.  Specifically, permissions in the umask are
       turned off from the mode argument to open(2) and mkdir(2).

I still see your use-case, maybe the relevant default permission could be exposed for you to modify.

You might still be better off just using a dedicated aptly user and sudo, doas or similar shenanigans to accomplish your goal of collaborative aptly management.

[Hawk777]

Yes, sorry, perhaps I worded it poorly; I’m quite well versed with how umask works, so I know that, from a technical perspective, a program is perfectly within its rights to choose whatever permission bits it wants. It’s just that, as a convention, programs usually use 0666 or 0777 unless there’s a good reason to do otherwise. Text editor? 0666. touch? 0666. Shell redirection? 0666. So what’s aptly’s reason for doing otherwise? Why does it behave differently from the majority of software, which lets the user have full control via umask?

[Hawk777]

As for using sudo, that seems like overkill (not to mention un-ergonomic, since you have to prepend every command with it). Groups are a thing, the very reason for them to exist is to allow multiple users to access shared resources. Why isn’t that the most obvious tool for this purpose?