SUMMARY Using a database with more than one user needs appropriate permissions if you will allow others to tag images or even add images to the DB. index.xml should be rw-rw-... for people in the group to be able to tag and save. .thumbnails/* should either be rw-r--... or rw-rw-... (the fist allows only 1 person to update the thumbnails, the second allows that for all). Unfortunately KPA changes the setting of index.xml to rw-r--... of .thumbnails/thumbnailindex to rw-rw-... and of .thumbnails/thumb-0 to rw-r--... When other users access the DB and do changes, the ownership of files will change too. This is a problem, when at the same time the permissions are set to more restrictive settings than before (rw-rw- to rw-r--). Here is a log (with the unnecessary lines deleted): as@wshome5:~/Lokal/tmp/testkpa> ll -a -rw-rw-r-- 1 as users 45056 5. Jun 17:34 exif-info.db -rw-rw-r-- 1 as users 21038 5. Jun 17:35 index.xml drwxrwxr-x 2 as users 4096 5. Jun 17:34 t1 drwxr-xr-x 2 as users 4096 5. Jun 17:35 .thumbnails as@wshome5:~/Lokal/tmp/testkpa> chmod g-w .thumbnails/* as@wshome5:~/Lokal/tmp/testkpa> ll .thumbnails/ -rw-r--r-- 1 as users 1082721 5. Jun 17:34 thumb-0 -rw-r--r-- 1 as users 6322 5. Jun 17:35 thumbnailindex as@wshome5:~/Lokal/tmp/testkpa> cp ../Day201004/I09993* t1 as@wshome5:~/Lokal/tmp/testkpa> kphotoalbum -c index.xml --- view the new files as the original owner and save --- as@wshome5:~/Lokal/tmp/testkpa> ll -a -rw-r--r-- 1 as users 35138 5. Jun 17:38 index.xml <== permissions have changed drwxrwxr-x 2 as users 12288 5. Jun 17:37 t1 drwxr-xr-x 2 as users 4096 5. Jun 17:38 .thumbnails as@wshome5:~/Lokal/tmp/testkpa> ll .thumbnails/ insgesamt 1772 -rw-r--r-- 1 as users 1801984 5. Jun 17:38 thumb-0 -rw-rw-r-- 1 as users 10922 5. Jun 17:38 thumbnailindex <== permissions have changed --- Now I reset everything to rw-rw-... (also the thumbnails) and add a few images as another user (test) as@wshome5:~/Lokal/tmp/testkpa> ll -a -rw-r--r-- 1 test users 79638 5. Jun 17:52 index.xml <== permissions AND owner have changed -rw-rw-r-- 1 as users 7268 5. Jun 17:48 index.xml~0003~.zip -rw-r--r-- 1 test users 10048 5. Jun 17:52 index.xml~0004~.zip drwxrwxr-x 2 as users 20480 5. Jun 17:52 t1 drwxrwxr-x 2 as users 4096 5. Jun 17:53 .thumbnails as@wshome5:~/Lokal/tmp/testkpa> ll .thumbnails/ insgesamt 3352 -rw-r--r-- 1 test users 3403652 5. Jun 17:53 thumb-0 <== permissions and owner have changed -rw-rw-r-- 1 test users 24722 5. Jun 17:53 thumbnailindex <== owner has changed --- reset the ownership and permissions to "admin-only" settings (still letting others tag and save): as@wshome5:~/Lokal/tmp/testkpa> ll -a -rw-rw-r-- 1 as users 79638 5. Jun 17:52 index.xml drwxr-xr-x 2 as users 4096 5. Jun 17:53 .thumbnails as@wshome5:~/Lokal/tmp/testkpa> ll .thumbnails/ -rw-r--r-- 1 as users 3403652 5. Jun 17:53 thumb-0 -rw-r--r-- 1 as users 24722 5. Jun 17:53 thumbnailindex --- let the other user do stuff (add images and tag something) --- rebuilding the thumbnails fails (predictably) for the other user as@wshome5:~/Lokal/tmp/testkpa> ll -a -rw-r--r-- 1 test users 94846 5. Jun 18:14 index.xml <== permissions and owner have changed --- look at the database as original owner (as) tag and save as@wshome5:~/Lokal/tmp/testkpa> ll -a -rw-r--r-- 1 as users 143004 5. Jun 18:18 index.xml <== owner has changed (magic!) as@wshome5:~/Lokal/tmp/testkpa> ll .thumbnails/ insgesamt 4212 -rw-r--r-- 1 as users 4276567 5. Jun 18:18 thumb-0 -rw-rw-r-- 1 as users 29322 5. Jun 18:18 thumbnailindex <== new thumbs have been generated (but permissions have changed again!) OBSERVED RESULT I see inconsistent settings in .thumbnails (the auto-settings are different for thumb-0 and thumbnailindex) I see changes of ownership of these files and of the index.xml file I see change in permissions and ownership of the index.xml file which seem to have no effect whatsoever (the magic lies in the backup files). EXPECTED RESULT When I set the permissions to some value, I expect them to stay the way I set them. However, I understand that the permissions on the index file are kept in the backup files and each index file is in effect a new copy (thus the magic). Allowing write access to a file, I do not expect the file to change ownership (and permissions). I especially do not like the different settings for the content of .thumbnails (rw-r-- for the thumb-0 and rw-rw- for the thumbnailindex). I could live with the "admin settings", because then nobody could trash the thumbnails. Normally this does not happen as the thumb-0 file is still write protected. Disaster is waiting to happen, if the thumb-0 file is just "full" and another thumb-1 files is created by the other user. The "magic" with the index files does not work with the thumb-X files. Thus the other user will just "take them away from me" when I allow her write access. CHANGE I WOULD WISH FOR When the thumb-X files are RW for the group they must stay so (even if somebody else becomes the owner). Changing the owner of existing files is not nice. SOFTWARE/OS VERSIONS Linux/KDE Plasma: openSuse Leap 15.2 KPA: v5.7.0-264-g36a530b7 KDE Frameworks 5.71.0 Qt 5.12.7 (kompiliert gegen 5.12.7)
Thanks for the detailed report!
Git commit d6d3d67a471f9000bd3679ce42442c96035239f7 by Johannes Zarl-Zierl. Committed on 24/12/2022 at 11:36. Pushed by johanneszarl into branch 'master'. Set QFile::WriteGroup permissions on created files Until now, kphotoalbum would only set QFile::WriteGroup permissions for the thumbnailindex, but no other files created by kphotoalbum. Setting this permission on all generated files makes it easier to use kphotoalbum with image databases shared by several user accounts. This affects the following files: - index.xml - exif-info.db - .thumbnails/thumbnailindex (no change) - .thumbnails/thumb-* - .videoThumbnails/* M +8 -1 BackgroundJobs/ExtractOneThumbnailJob.cpp M +16 -1 Utilities/ImageUtil.cpp M +8 -0 XMLDB/FileWriter.cpp M +7 -3 lib/kpaexif/Database.cpp M +5 -1 lib/kpathumbnails/ThumbnailCache.cpp https://invent.kde.org/graphics/kphotoalbum/commit/d6d3d67a471f9000bd3679ce42442c96035239f7
This should work now. Merry christmas!
Works as described and will be much better for us. Thanks for the unexpected Christmas present! Merry Christmas!