[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[SOLVED] Re: Able to write to read-only pdf files



On 15.08.21 00:06, Adriano Vilela Barbosa wrote:
On Sat, 14 Aug 2021 at 18:05, Adriano Vilela Barbosa
<adriano.vilela@gmail.com> wrote:

On Sat, 14 Aug 2021 at 16:49, bruno zanetti <bzanetti00@gmail.com> wrote:

Il giorno sab 14 ago 2021 alle ore 20:20 Adriano Vilela Barbosa <adriano.vilela@gmail.com> ha scritto:

On Sat, 14 Aug 2021 at 12:54, bruno zanetti <bzanetti00@gmail.com> wrote:

Il giorno sab 14 ago 2021 alle ore 15:39 Adriano Vilela Barbosa <adriano.vilela@gmail.com> ha scritto:

Hello,

Yesterday I came across a very weird behavior while annotating a pdf
file in Okular. Long story short: I opened a read-only pdf file
(permissions: 400), inserted some comments and hit the save button. At
this point, I thought I had been working on a write-enabled copy of
the file. After a while, I realized that I was actually working on the
read-only version of the file, that somehow got saved to disk when I
hit the save icon. Okular was not only able to save the file to disk,
but the file permissions were changed to 644.

I initially thought this was an Okular problem. However, after some
more testing, I was able to reproduce the problem with Xournal. This
makes me think that the problem is not with Okular or Xournal, but
with some common library used by both of these packages (maybe
libpoppler?).

Has anybody had this problem? Can anybody reproduce it?

I'm using Debian testing.

Thanks a lot,

Adriano


Hi Adriano,
the read-only permission on the pdf file just prevents it's contents to be changed. It still can be deleted if the directory it belongs to is not write protected.
Editor programs usually do not directly change the contents of a file but rather save them to a temporary new one (with default permissions), delete the original and then rename the new file replacing the original one. I don't know if Okular works this way, but I think it quite likely does.

Have a good release day!

Bruno



Hi Bruno,

Thanks for your reply.

Indeed, what you describe may be what's happening. If I change the
permissions of the directory where the file is to read-only, I get an
error message when trying to save the file. The error message says the
file could not be saved (error: access denied), and also says that it
could not write to file.pdf.part (this .part file must be temporary
file you mentioned).

I understand this mechanism, but I think this is quite controversial
and problematic. I mean, as an end user I don't care what the editor
is doing behind the scenes; it just shouldn't be able to modify a file
marked as read-only.

This is the first time I came across this behavior. No text editor I
ever used does this; LibreOffice doesn't do it either (rather, it
shows a message saying the document is open in read-only and shows an
"Edit Document" button, which allows you to edit the document and then
save it under a different name).

The question is: should I file a bug report somewhere? I really don't
want editors overwriting my read-only documents...

Thanks again,

Adriano


Well, some editors take care of not overwriting read-only files, some others (like kate, kwite) don't...
But I second your reasoning, the right behaviour IMHO would be to respect the file permissions, regardless of the mechanism of the underlying filesystem.
I'd suggest you report the issue on bugs.kde.org since it doesn't seem to be a debian specific issue.

Best

Bruno


Hi Bruno,

At least on my system (Debian Testing), I can't overwrite a read-only
file with either kwrite or kate.

I'm going to report a bug upstream and post the link here.

Adriano

Here's the bug report I filed:

https://bugs.kde.org/show_bug.cgi?id=440986

Adriano


I just saw that upstream it indeed was accepted to be a bug, became discussed, and subsequently became solved. In the correct version there will now be shown a message "File could not be saved in [...location...]. Try to save it to another location." It might take some time to see this corrected version to appear also in Debian, but I think we have good reasons to assume that it will come.

Adriano, thanks a lot to have brought up this thread, I learned important things from it, I did not imagine this "overwrite" to be possible, but learned that in certain situation it indeed is possible by following the idea of first saving to a new file, then deleting the old one, and finally renaming the new one back to the name of the former file. The upstream discussion also mentions that some like this "overwritten" file version then of course does not reflect the original file attributes (and ACL) no more.

So, from now on I am aware about the risk, that a programm implementation can decide to go for this pathway and by this working around a filesystem based write protection which a user for safety might have placed on a file, that filesystem flags are not as safe as I by now assumed them to be.

Thanks, and best wishes,
Marco


Reply to: