mrdevel2002-ui opened a new pull request, #3517:
URL: https://github.com/apache/tika/pull/3517
`IgniteStoreServer`, the embedded Ignite 3 node that tika-grpc starts for
`configStoreType=ignite`, puts its work directory at the fixed path
`java.io.tmpdir/tika-ignite-work` unless `ignite.work.dir` is set, creates it
with `Files.createDirectories` (so umask permissions, 0755 under the usual 022)
and wipes whatever is there on each start. Ignite persists the config store
table under that directory, so every fetcher and emitter config saved at
runtime, credentials included, ends up on disk in the shared temp dir where any
local user can read it. I checked with a store put of
`{"accessKey":"AKIAREPRO","secretKey":"hunter2-repro-secret"}`: the secret is
in `tika-ignite-work/partitions/log/000004.log`, mode 0644, inside a 0755
directory. The fixed name is the second problem. Another local user can create
`tika-ignite-work` first; the sticky bit on the temp dir stops Tika from
deleting it, `createDirectories` is happy that it exists, and the node then
writes `ignite-config.conf` and
all of its data into a directory that user owns and can rewrite between the
write and Ignite reading it.
The fix adds `prepareWorkDir`: with no `ignite.work.dir` it creates a unique
owner-only directory with `Files.createTempDirectory`, which is what every
other temp directory in the tree already does (`tika-unrar-`, `tika-render-`,
`libpst-`, the pipes fork dirs), and `close()` removes it, since the old fixed
directory was wiped on the next start anyway so nothing survived a restart
before either. A configured `ignite.work.dir` keeps the existing
empty-and-reuse behavior; that path is the operator's choice. The data files
Ignite writes inside are still 0644, but they sit under a 0700 directory, so I
left Ignite's own file creation alone.
`IgniteStoreServerTest` covers both paths: the default directory is unique,
lives under `java.io.tmpdir` and is owner-only, and a configured directory is
emptied and kept. Run on this branch, the reproducer above shows
`tika-ignite-work-<random>` with `rwx------`, gone after `close()`. `./mvnw
clean install` of `tika-pipes-config-store-ignite` (both test classes,
checkstyle, spotless, forbidden-apis) is green; `IgniteConfigStoreTest` hit an
Ignite planner timeout once on my slow machine in an unrelated test's setup and
passed on the rerun.
- [ ] open issue on the Tika issue tracker: not filed yet, happy to open one
or have it linked
- [ ] issue ID in the PR title and commit message: pending the issue above
- [x] commits are squashed into a single one
- [x] Tika builds and unit tests pass with `./mvnw clean install` (affected
module)
- [x] generative AI tool used: the commit carries `Generated-by:` per the
ASF Generative Tooling Guidance.
- [x] no conflicts with the recent `main` branch
- [ ] new downstream module added to `tika-bom/pom.xml`: not applicable
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
