[Bug 145252] New: Umask settings used for album directory, not for image files

[giaracca]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=145252         
           Summary: Umask settings used for album directory, not for image
                    files
           Product: digikam
           Version: unspecified
          Platform: Ubuntu Packages
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: general
        AssignedTo: digikam-devel kde org
        ReportedBy: giaracca flashmail com


Version:            (using KDE KDE 3.5.6)
Installed from:    Ubuntu Packages
OS:                Linux

I'm trying to find a way to share digikam albums with other user of my machine. I managed to give write permission to the database file and to album directory.
Here
http://mail.kde.org/pipermail/digikam-users/2005-September/000430.html 
I found the suggestion to use umask settings to allow group write to albums.
If I start digikam with the command
$ umask 0002; digikam
new albums directory are created with the correct permissions, but imported photos does not follow umask settings. AFAIK they are imported with the original permission.
So I'm asking if this is the intended behaviour or not. Why follow the umask for directory and not for image files?
Thanks for your wonderful application!
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[giaracca]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=145252         
giaracca flashmail com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gianpaolo.racca gmail com
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Arnd Baecker]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=145252         




------- Additional Comments From arnd.baecker web de  2007-05-10 07:43 -------
I am also puzzled about the permissions in the context of digikam,
for example why do freshly generated thumbs have
"-rw-------" as rights, even though the umask is on 022.
(i.e. freshly generated files via touch are "-rw-r--r--"),
http://mail.kde.org/pipermail/digikam-devel/2007-April/012183.html
(I am using debian etch, if that matters here at all).

Independent of this, I am not sure whether it is
a good idea to share digikam albums in the way you intend.
At least you have absolutely make sure that digikam is never run
by two users at the same time. Otherwise it is very likely
that you damage your database.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Arnd Baecker]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=145252         




------- Additional Comments From arnd.baecker web de  2007-10-16 17:35 -------
I had a look at the rights problem concerning
the thumbnails first:
Thumbnail generation is done in
  graphics/digikam/kioslave/digikamthumbnail.cpp
where one finds the construct
  KTempFile temp(thumbPath + "-digikam-", ".png");
into which then the thumbnail is written by
  img.save(temp.name(), "PNG", 0);
After this the file is renamed.
According to the documentation of KTempFile the default mode is 0600,
i.e. -rw-------

So if there is a way to create the temporary
file with the current umask, all should be
fine.

Note that in digikam/kioslave/digikamalbums.cpp
one finds this approach:
    if ( ::mkdir( _path.data(), 0777 /*umask will be applied*/ ) != 0 )

So to me it seems that
  // Using 0777 as mode means that the umask will be applied.
  KTempFile temp(thumbPath + "-digikam-", ".png", 0777 );
should solve this problem.

Does this sound reasonable, or are there any security (or other
problems?) with this approach?

I suspect that the other rights problems are similar ...

Best, Arnd
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Arnd Baecker]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=145252         




------- Additional Comments From arnd.baecker web de  2007-10-16 17:46 -------
Yes, for images changed in the image editor it should be just the same: in
graphics/digikam/utilities/imageeditor/editor/editorwindow.cpp
the construct
  m_savingContext->saveTempFile   = new KTempFile(newURL.directory(false),      
       ".digikamtempfile.tmp");
is used.

So if changing the mode of the temporary files in the first place
makes sense, I will write and test a patch later this evening ...
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=145252         
caulier.gilles gmail com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ach mpe mpg de



------- Additional Comments From caulier.gilles gmail com  2007-10-16 18:11 -------
Arnd,

It sound resonable for me but i can lack few security rules here... I would to have the feedback from system admin for example.

Achim, have you few comments ?

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Arnd Baecker]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=145252         




------- Additional Comments From arnd.baecker web de  2007-10-18 18:59 -------
Created an attachment (id=21852)
 --> (http://bugs.kde.org/attachment.cgi?id=21852&action=view)
use umask settting for thumbnails and edited images

The attached patch solves the problem for me,
i.e. modified images and newly generated thumbs have
-rw-r--r-- (when the umask is on 022)

If there should be any security problem, I would guess that the whole approach.

of using temporary files needs to be re-thought.
Therefore, I would suggest to apply the patch (after testing, of course... ;-)
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=145252         




------- Additional Comments From ach mpe mpg de  2007-10-19 13:56 -------
About caches (thumbnail, fulltext indices, htmlpages ...):

The reason they should be readable only by the owner is that
one should only have access to the cached info, if you have
access to the original data.

If e.g. another person has access to an image depends on
each componemt of the full path to the image.  Nothing one can
map into a single protection mask of a file.   Keeping caches
and access permissions of external images in sync is impossible.
Ditto for date base entries. (fwiw digikam3.db violates this
by default)

One way to circumvent this problem is used in (s)locate:  It
collects everything as root, but readable only by _one_ specially
empowered executable.  And this program makes sure that only meta
data are delivered if the user has access to the original data.


If one lowers the access to meta information, it should never be
done by default.  If user does it, should be informed about the
consequences.

Achim
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Arnd Baecker]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=145252         




------- Additional Comments From arnd.baecker web de  2007-10-19 14:19 -------
Hi Achim,

well, I have to admit, that I don't fully understand the consequences
of your description to the original problem (or patch),
i.e. what should we do?

To me the situation seems the following:
- Currently (i.e. without patch)
  thumbnails and modified images result in files with
  -rw-------
  Any value of the current umask is ignored.
- With the patch above, the umask information is used
   so that thumbnails/modified images may end up as
  -rw-r--r--
  (if umask is set to 022)
  or
  -rw-------
  (for a different setting of the umask)
 
  So this is in full control of the user and behaves in the same
  way as, for example `touch new_file_to_see_its_rights`.

  This also leads to a consistent behaviour, as for newly created
   directories the mode 0777 is in digikamalbums.cpp.

So for new files, I would think that respecting the umask
should be ok.

For thumbnails I do understand the problem that this might make
files visible to other users, which originally are not visible
(due to paths right settings etc.).

So the question is: what should we do?
Should this be made a configuration option for the thumbnails,
or better left as is?
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=145252         




------- Additional Comments From caulier.gilles gmail com  2007-10-19 14:26 -------
>So for new files, I would think that respecting the umask
>should be ok.

Fine for me too...

>For thumbnails I do understand the problem that this might make
>files visible to other users, which originally are not visible
>(due to paths right settings etc.).

>So the question is: what should we do?
>Should this be made a configuration option for the thumbnails,
<or better left as is?

No need a setting for thumb. This will bloat the config (:=))), and most users we don't care about...

Why not to replicate the same umask from original image to thumb files ?

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Arnd Baecker]

> Why not to replicate the same umask from original image to thumb files ?

This could expose files which were previously not visible
due to directory rights setting
(And this was one of Achim's main points, right?)

I just checked: konquerer creates thumbs also only as -rw-------
(independent of the mode of the original file)
so presumably we should do the same...


_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Arnd Baecker]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=145252         




------- Additional Comments From arnd.baecker web de  2007-10-19 15:11 -------
> Why not to replicate the same umask from original image to thumb files ?


This could expose files which were previously not visible
due to directory rights setting
(And this was one of Achim's main points, right?)

I just checked: konquerer creates thumbs also only as -rw-------
(independent of the mode of the original file)
so presumably we should do the same...
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=145252         




------- Additional Comments From ach mpe mpg de  2007-10-19 15:12 -------
> >So for new files, I would think that respecting the umask
> >should be ok.
>
> Fine for me too...


 new files: I agreed.
 modified files: use same protection as the unmodified version had.

> >For thumbnails I do understand the problem that this might make
> >files visible to other users, which originally are not visible
> >(due to paths right settings etc.).
>
> >So the question is: what should we do?
> >Should this be made a configuration option for the thumbnails,
> <or better left as is?
>
> No need a setting for thumb. This will bloat the config (:=))), and most users we don't care about...]
>
> Why not to replicate the same umask from original image to thumb files ?

Nope.  That's as I tried to explain before IMHO bad design.

IMHO a primitive but clean solution to sharing thumb problem could be
use something like LibraryPathAccess=[default|private|shared] (without
GUI until we properly support it ;)

If set to 'shared' search/create first

        ~/Pictures/.thumbnails/...

with thumb having the same protection as the image when created/updated.


Default == as it's right now.  Optional: For 'private'
~/.thumbnail is used and ~/Pictures/ (700) and digikam.db (600), with
as a start checking (changing after asking) protection ~/Picture and
.digikam*.db).


How to realize write access is left as an excercise for the user for
now ;)  To make it possible digikam should use try use umask for
new stuff and keep protection when modifying files.

Achim
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=145252         




------- Additional Comments From caulier.gilles gmail com  2007-10-19 15:23 -------
>I just checked: konquerer creates thumbs also only as -rw-------
>(independent of the mode of the original file)
>so presumably we should do the same...

Right, because digiKam and Konqueror share thumbs. No others way can be done...

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=145252         




------- Additional Comments From ach mpe mpg de  2007-10-19 15:30 -------
yes.

Using ~/.thumbnails 'mean' I want to share it with all my gnome/kde apps
and as this case is used 'behind' the scene --> play save, use mode 600.

Using ~/Pictures/.thumbnails/ would imply the intent to share the thumbs
with digikam.

AFAIR the freedesktop spec (argl. access denied for http://jens.triq.net/thumbnail-spec/index.html as referenced by f.d.o)
has a search patch  (e.g. for prepared thumbs in readonly CDROM).
_Maybe_ just creating  Pictures/.thumbnails/*/ would make all apps
managing thumb like f.d.o  spec use them  (that would be really cool ;)
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Arnd Baecker]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=145252         




------- Additional Comments From arnd.baecker web de  2007-10-19 16:12 -------
Well, for the moment I think it is simplest to:
a) don't touch the thumbnails
b) new files: respect umask
   modified files: use same protection as the unmodified version had.
   (as Achim suggested above)

For the second case in b): How do I get the mode
from the file?
I.e. the code will (presumably) look like this:
  mode = 0666;
  if (m_savingContext->destinationExisted)
      mode = CALL_TO_GET_THE_MODE_OF_THE_ORIGINAL(m_savingContext->srcURL);
I could not find a method of the KURL class which would provide this.
Is there any KDE/Qt way to do it, or what is the best approach here?

Thanks, Arnd
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=145252         




------- Additional Comments From caulier.gilles gmail com  2007-10-19 16:36 -------
Arnd,

Are you take a look in this method : EditorWindow::moveFile()

You need to use ::stat() to get file mode. EditorWindow::moveFile() do it already...

But i don't know where is the problem in image editor with temp file generated when a new image is saved, because EditorWindow::moveFile() is called after than temp file is created to create/overwrite target file. If you check code in this method, you will see than mode is already get and restored as well...

If something must be done to solve this file, this must be done in EditorWindow::moveFile(). Right ?

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Arnd Baecker]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=145252         
arnd.baecker web de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #21852|0                           |1
        is obsolete|                            |



------- Additional Comments From arnd.baecker web de  2007-10-19 21:43 -------
Created an attachment (id=21865)
 --> (http://bugs.kde.org/attachment.cgi?id=21865&action=view)
respect umask for newly created files.

> If something must be done to solve this file, this must be done in
EditorWind$

Yes - you are (of course) right!
The relevant part is
    // store old permissions
    mode_t filePermissions = S_IREAD | S_IWRITE;
(If a file previously exists, `filePermissions` is modified, so that
its protections are used.)
So instead of S_IREAD | S_IWRITE, the umask has to
be taken into account.

The attached patch tries to do so and also applies the permissions
in both situations of overwritten or newly created files.

Achim, could you maybe test the patch, if everything is ok?

Best, Arnd
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Arnd Baecker]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=145252         
arnd.baecker web de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
      everconfirmed|0                           |1



------- Additional Comments From arnd.baecker web de  2007-11-01 10:52 -------
Achim, could you maybe have a look at this patch?
(It would be nice to get this into 0.9.3 and close the bug ;-)
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=145252         




------- Additional Comments From fabrice.jade freesbee fr  2008-02-06 23:10 -------
Is it the same problem that occurs with showfoto?
All is right with digikam for me, but permissions changes when I edit photos.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel