Do not `chown` files (unless the new file has a different UID/GID)

[Ciprian Dorin Craciun]

I've observed that in safeio.WriteFile, line 41, if err = tmpf.Chown(uid, gid); err != nil { is called, regardless if the temporary file has the expected UID/GID or not. In practice, as long as one chown's to the same user / group, nothing usually happens, however,

However, when trying to run chasquid under systemd with a strict SECCOMP filter (one that doesn't allow chown and related functions), chasquid is killed.

chasquid/internal/safeio/safeio.go

Lines 41 to 47 in 795f2a7

 if uid, gid := getOwner(filename); uid >= 0 { 
 	if err = tmpf.Chown(uid, gid); err != nil { 
 		tmpf.Close() 
 		os.Remove(tmpf.Name()) 
 		return err 
 	} 
 } 

---

I'm not sure if this is an actual bug, because it's hit only in such corner-cases as when running under SECCOMP. However, I don't think chasquid should try to touch files in non-standard ways, especially configuration files (that happened to trigger the issue above). (The issue was triggered by a STS state file update.)

[Alberto Bertogli]

Hi! Thanks a lot for reporting this!

I'm not sure if this is an actual bug, because it's hit only in such corner-cases as when running under SECCOMP.

I don't know either, but I agree it is an unnecessary call in that particular case. The reason it exists is that that library is also used from command-line tools which can run as root, see commit cda11e0.

I could make the library only Chown if the ownership differs. It does add some complexity though, but it should result in cleaner operations. I will experiment a bit with this change and let you know how it goes.

However, I don't think chasquid should try to touch files in non-standard ways, especially configuration files (that happened to trigger the issue above). (The issue was triggered by a STS state file update.)

Regardless of the above, I don't agree with this part, though: the STS files, and anything in the data_dir directory (/var/lib/chasquid by default), is not configuration, but internal service data. It is written by the daemon, and manipulated as needed. I don't think a chown on files written by the daemon itself is non-standard, even if I agree in that particular situation it is an unnecessary call.