GNOME Bugzilla – Bug 360265
File permission / ownership not respected
Last modified: 2006-10-06 22:57:44 UTC
gthumb is not respecting file permissions or ownerships properly. Confirmed with CVS and 2.7.7. If I: chmod 444 sample.jpg and rotate/apply sample.jpg, it overwrites the file, even though it is marked read-only! In fact, if I: chown root.root sample.jpg and run gthumb as me (non-root), it overwrites the file, and assigns ownership to me. So, initially in my home directory (/home/mjc) I have: [mjc@server2 bin]$ ll ~ -r--r--r-- 1 root root 80615 Oct 6 15:43 wagon1.jpg [mjc@server2 bin]$ ./gthumb ~/wagon1.jpg and hit "]" to rotate, close gthumb, and then I get: [mjc@server2 bin]$ ll ~ -r--r--r-- 1 mjc mjc 80317 Oct 6 15:47 wagon1.jpg Initially reported here: http://bugzilla.gnome.org/show_bug.cgi?id=343867#c119 and confirmed here: http://bugzilla.gnome.org/show_bug.cgi?id=343867#c122 This seems to be a major security issues, especially coupled with bug 358894.
I think I get it. When gthumb modifies an image (or at least when it rotates one), it doesn't actually modify the file. It first writes a new file to disk, then deletes the old one and renames the new file (using 'mv -f'; see src/rotation-utils.c). You're not actually modifying the file; you're modifying the directory containing the file. If you do have write permission to the directory, this is allowed. It would still be nice for gthumb to deny overwriting files that it doesn't have write permission to. But this isn't actually a security issue. Rennie
Yes, you're right. It's within the unix permissions scheme... but it is surprising! I'm lowering the severity level. I'm not sure whether to keep it as a bug or not.
Closing bug. Valid (though subtle) behaviour.