Hi Alex,
I think you're missing the main point here: a file was deleted or was
deleted accidentally by an out of band application (git). Applications
cannot be responsible for people with admin rights manually deleting
files within their directory trees. I know of no application that is,
ever, and that is regardless of whether the file is designated "content"
or "code", it's the same. Hands off the file tree is always the policy.
Writing internal defensive code is an enormous slippery slope, trying to
guard against all the various things people could possibly do to corrupt
an installation (code or data or configuration), and all of that
additional code would be there simply to fix what is effectively bad
behaviour on the part of a sysadmin. And every single line of additional
code in any application is code that has to be maintained.
I mean, I could go on, but this is simply not something I would advise be
considered requiring a fix. It's not remotely a fault of the application.
Cheers,
Murray
On 17/08/24 12:45, Alex O'Ree wrote:
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
--
...........................................................................
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
