I noticed recently that on Linux, schematic and board files now default to no group or world read. Where in the past those files were created with 0644 permissions, they are created wtth 0600 permissions. Sounds like a umask(0077) or umask(0066) has been added to the code somewhere.
It’s not a biggie but I prefer to allow group and world read permissions, and there doesn’t seem to be a preference to set the umask. I assume this is to prevent inadvertent exposure of info to others.
Maybe you think you don’t but certainly a program can affect the permissions when a file is created. The base system call for creading a file is creat(2) which has a second argument of mode. If the group and world permission bits are anded out, a file will not have those permission bits on. Generally most programs do creat(path, 0666) and let the user umask mask out the write bit on group and world. Maybe somebody thought KiCad code (or perhaps wx code) should do creat(path, 0600).
This is a different matter. Some Linux distros set the user umask to something a bit more restrictive, usually in the system profile. Yours is 0027, mine is 0022. Thus all my other programs create files with read for group and world, the 2 masks out write.
I just did an experiment. I took a project, updated the schematic date in the title block and saved it. Sure enough the .kicad_sch files both the main and child sheets had 0600 permissions where they had 0644 permissions previously. Maybe it has something to do with the way KiCad saves files to avoid problems with network file systems.
Maybe I’ll run a strace on the process some time.
Ok, here’s the result in the strace output. Turns out that KiCad does a chmod on the saved file, wonder why. Paths redacted for privacy.
But none of the other usual apps (browsers, editors, etc.) on Linux create files with those restrictions, so it’s unlikely to be libc. Maybe it’s a utility library routine to copy files or something like that to avoid the network file issues.
That might be a possibility. The temp file should acquire the permissions of the older version so as not to also turn on permission inadvertently.
Edit: In fact I suspect that’s it. man 3 mkstemp says:
The file is created with permissions 0600, that is, read plus write for
owner only. The returned file descriptor provides both read and write
access to the file. The file is opened with the open(2) O_EXCL flag,
guaranteeing that the caller is the process that creates the file.
I’ve never used strace but I gave it a try. I came up with an empty file on the grep outputted to a file. I may have done it wrong or there may have been nothing too see. If you are using a package I would suspect the friendly privacy police helped out.
What puzzles me is why KiCad did a chmod on the final saved file as my trace shows. My guess what happened is:
KiCad contained code to propagate the permissions of the old revision to the new one, which is the right thing to do
Code was added to save to a temp file first then rename
The permission transfer now propagated the permissions of the temp file to the new revision