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

Re: Re: Able to write to read-only pdf files



> > > > On 14.08.21 20:19, Adriano Vilela Barbosa wrote:
> > > >
> > > >     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
>
>
> Adriano, I am simply a user, not a developer. I fully agree with you and suggest to file a
> bug report. In 30 years computing I have never noticed and assumed something like this, and
> although the explanation of Bruno sounds reasonable, the behavior is not reasonable at all
> from the point of view of a user! Until you and Bruno mentioned this behavior, I would not
> even have expected this to be possible by the filesystem's policy and initially reading
> your original post suspect this even to be a filesystem bug! If data represented by a file
> name is marked read-only on the filesystem level, then for this file name the data should
> not be replaceable. If this technically would be possible, like Bruno suspects it, then
> this still doesn't make it right from the users point of view.
>
>
> ---
> Just my thoughts!
> Marco.

Hi Marco,

I totally agree with you. As I said, I also have never seen this
behavior before. However, if the mechanism described by Bruno is what
is actually happening (and I think it is, because of the error message
about the .part file I got when I changed the directory permissions),
I don't see how the file system could prevent that.

I'm going to file a bug report upstream.

Thanks,

Adriano


Reply to: