If a jar or system configuration is missing, sure thing. But this is
content. A missing attachment shouldn't break the whole web app.


On Fri, Aug 16, 2024 at 6:08 PM Murray Altheim <murra...@altheim.com> wrote:

> Hi Alex,
>
> I think what you should consider what you're asking. It's effectively
> stating that somebody should be able to manually go into an installation
> and delete files, and the app should still start up and recover, and
> not doing that would be a "denial of service attack"? No, not hardly.
> What's next? Deleting a JSP? If someone has access to the directory
> tree of an installation and is randomly deleting files they find,
> deleting an attachment is the same probability as deleting a JSP.
>
> The right answer to someone manually deleting files is that that someone
> has corrupted the installation. Nobody should have the expectation that
> they could go into an application and delete files. This is the same with
> every application. And that's not crazy. Like I said, go into your
> Windows laptop and delete a few files in the system directory, see what
> happens. It's exactly the thing.
>
> Protecting JSPWiki against someone with admin rights deleting files in
> the directory tree would be impossible.
>
> Cheers,
>
> Murray
>
> On 17/08/24 08:26, Alex O'Ree wrote:
> > honestly, this was discovered by accident. I have the wiki's contents in
> > git version control. added an attachment and did not check in the image
> and
> > deleted it, leaving behind the properties files.
> >
> > So... you think the right answer to a missing file is to fail to start
> the
> > web app? That's crazy to me. Flat out denial of service attack. Logging
> the
> > issue should be the fix, but causing start up to fail completely seems
> way
> > too extreme
> >
> >
> > On Thu, Aug 15, 2024 at 7:45 PM Murray Altheim <murra...@altheim.com>
> wrote:
> >
> >> If you are deleting the attachment file manually you're creating a
> >> situation where the software is no longer in sync with expectations.
> >> JSPWiki is charged with management of the files within its directory
> >> tree and can't be expected to protect those files from a sysadmin
> >> deleting them. This is akin to going in and deleting files or
> >> changing filenames in a MS Windows system directory.
> >>
> >> I don't see this as a bug in the software. Manually deleting files
> >> is the kind of thing that is by definition unsupported.
> >>
> >> Unless I'm misunderstanding the description provided...
> >>
> >> On 16/08/24 07:42, Alex O'Ree (Jira) wrote:
> >>> Alex O'Ree created JSPWIKI-1197:
> >>> -----------------------------------
> >>>
> >>>                Summary: Deleting an attachment via filesystem causes
> jsp
> >> wiki to complete crash
> >>>                    Key: JSPWIKI-1197
> >>>                    URL:
> >> https://issues.apache.org/jira/browse/JSPWIKI-1197
> >>>                Project: JSPWiki
> >>>             Issue Type: Bug
> >>>               Reporter: Alex O'Ree
> >>>
> >>>
> >>> * i created a wiki page, let's call it Foo
> >>>    * uploaded an attachment
> >>>    * stopped the server
> >>>    * delete the attachment file only from
> >> Foo-att/attachment.png-dir/1,png leaving behind the Foo-att directory
> and
> >> attachment.properties
> >>>    * start the server
> >>>
> >>> i got this dumped to std out
> >>>
> >>> 15:31:08.212 [main] ERROR
> >> org.apache.wiki.providers.BasicAttachmentProvider - Can't get attachment
> >> properties for Attachment [Foo/attachment.jpg;mod=null]
> >>> java.io.FileNotFoundException: No such file:
> >> C:\test\wiki\Foo-att\Foo/attachment.png-dir\0.png exists.
> >>>           at
> >>
> org.apache.wiki.providers.BasicAttachmentProvider.findFile(BasicAttachmentProvider.java:330)
> >> ~[jspwiki-main-2.12.2.jar:2.12.2]
> >>>           at
> >>
> org.apache.wiki.providers.BasicAttachmentProvider.getAttachmentInfo(BasicAttachmentProvider.java:471)
> >> [jspwiki-main-2.12.2.jar:2.12.2]
> >>>           at
> >>
> org.apache.wiki.providers.BasicAttachmentProvider.listAttachments(BasicAttachmentProvider.java:379)
> >> [jspwiki-main-2.12.2.jar:2.12.2]
> >>>           at
> >>
> org.apache.wiki.providers.BasicAttachmentProvider.listAllChanged(BasicAttachmentProvider.java:422)
> >> [jspwiki-main-2.12.2.jar:2.12.2]
> >>>           at
> >>
> org.apache.wiki.providers.CachingAttachmentProvider.listAllChanged(CachingAttachmentProvider.java:141)
> >> [jspwiki-main-2.12.2.jar:2.12.2]
> >>>           at
> >>
> org.apache.wiki.attachment.DefaultAttachmentManager.getAllAttachments(DefaultAttachmentManager.java:287)
> >> [jspwiki-main-2.12.2.jar:2.12.2]
> >>>           at
> >> org.apache.wiki.WikiEngine.initReferenceManager(WikiEngine.java:469)
> >> [jspwiki-main-2.12.2.jar:2.12.2]
> >>>           at org.apache.wiki.WikiEngine.initialize(WikiEngine.java:307)
> >> [jspwiki-main-2.12.2.jar:2.12.2]
> >>>           at org.apache.wiki.api.core.Engine.start(Engine.java:434)
> >> [jspwiki-api-2.12.2.jar:2.12.2]
> >>>           at
> org.apache.wiki.WikiEngine.getInstance(WikiEngine.java:188)
> >> [jspwiki-main-2.12.2.jar:2.12.2]
> >>>           at
> >>
> org.apache.wiki.spi.EngineSPIDefaultImpl.find(EngineSPIDefaultImpl.java:41)
> >> [jspwiki-main-2.12.2.jar:2.12.2]
> >>>           at org.apache.wiki.api.spi.EngineDSL.find(EngineDSL.java:65)
> >> [jspwiki-api-2.12.2.jar:2.12.2]
> >>>           at
> >> org.apache.wiki.ui.WikiServletFilter.init(WikiServletFilter.java:81)
> >> [jspwiki-main-2.12.2.jar:2.12.2]
> >>>           at
> >>
> org.apache.catalina.core.ApplicationFilterConfig.initFilter(ApplicationFilterConfig.java:262)
> >> [catalina.jar:9.0.85]
> >>>           at
> >>
> org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:244)
> >> [catalina.jar:9.0.85]
> >>>           at
> >>
> org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:97)
> >> [catalina.jar:9.0.85]
> >>>           at
> >>
> org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4311)
> >> [catalina.jar:9.0.85]
> >>>
> >>> and no wiki pages will be served. looks like it fails the bootup
> process
> >> and tomcat undeploys the app.
> >>>
> >>>
> >>>
> >>> --
> >>> This message was sent by Atlassian Jira
> >>> (v8.20.10#820010)
> >>>
> >>
> >> --
> >>
> >>
> ...........................................................................
> >> Murray Altheim <murray18 at altheim dot com>                       = =
> ===
> >> http://www.altheim.com/murray/                                     ===
> >> ===
> >>                                                                      = =
> >> ===
> >>       In the evening
> >>       The rice leaves in the garden
> >>       Rustle in the autumn wind
> >>       That blows through my reed hut.
> >>              -- Minamoto no Tsunenobu
> >>
> >>
> >
>
> --
>
> ...........................................................................
> Murray Altheim <murray18 at altheim dot com>                       = =  ===
> http://www.altheim.com/murray/                                     ===
> ===
>                                                                     = =
> ===
>      In the evening
>      The rice leaves in the garden
>      Rustle in the autumn wind
>      That blows through my reed hut.
>             -- Minamoto no Tsunenobu
>
>

Reply via email to