do not apply POSIX file attributes through symbolic links

[jmestwa-coder]

PosixViewAttribute applies permissions and ownership through symbolic links:

• FileUtils.defineFilePosixAttributeView looks the view up without NOFOLLOW_LINKS, so setPermissions/setOwner/setGroup land on the link target
• walkFileTree still hands symlinks to visitFile, so the followLinks="false" default documented on AbstractPathAction has no effect here
• a link planted in basePath whose name matches the PathCondition glob redirects the chmod/chown onto any file the process can reach
• FileManager.defineAttributeView goes through the same helper

Requesting the view with NOFOLLOW_LINKS makes the change fail on a link rather than hit its target, and the visitor now skips symlinks so a planted one does not abort the rollover action.

Checklist

• Base your changes on 2.x branch if you are targeting Log4j 2; use main otherwise
• ./mvnw verify succeeds (the build instructions)
• Non-trivial changes contain an entry file in the src/changelog/.2.x.x directory
• Tests are provided

[jmestwa-coder]

any update?

[ramanathan1504]

Suggested change

	final PosixFileAttributeView view =
	final PosixFileAttributeView view = Files.getFileAttributeView(path, PosixFileAttributeView.class);

[ramanathan1504]

This helper is also called by FileManager:289 and, through defineAttributeView, by RollingFileManager:409 and RollingRandomAccessFileManager:270,333 — on the appender's own configured fileName, not on anything an attacker planted. If that name is a symlink I get FileSystemException: Too many levels of symbolic links, which FileManager swallows into LOGGER.error("Could not define attribute view …"), so permissions are silently not applied. Could this line stay as it was, and let the visitor guard do the work? I tried it locally and both followLinks modes then behave, with your PosixViewAttributeActionTest still passing. The import java.nio.file.LinkOption; added at the top can go with it.

[ramanathan1504]

Permissions never land on the link — setPermissions throws, which is why the new FileUtilsTest has to swallow an IOException. Only owner and group do, via lchown. If the lookup goes back to following, this paragraph can go entirely.

[ramanathan1504]

followLinks="true" is documented as supported — manual/appenders/rolling-file.adoc:1033, with its own security warning — but under FOLLOW_LINKS the attributes come from stat, so attrs.isSymbolicLink() is false and this guard never fires. Gating the skip on the action's own setting makes both modes work. isFollowSymbolicLinks() is already public on AbstractPathAction:143.

Suggested change

	if (attrs.isSymbolicLink()) {
	if (!isFollowSymbolicLinks() && attrs.isSymbolicLink()) {

[ramanathan1504]

@Test
void testSymbolicLinksAreFollowedWhenConfigured(@TempDir final Path tempDir) throws Exception {
    final Path outsider = tempDir.resolve("outsider.txt");
    Files.write(outsider, "secret".getBytes(StandardCharsets.UTF_8));
    Files.setPosixFilePermissions(outsider, PosixFilePermissions.fromString("rw-------"));

    final Path baseDir = Files.createDirectory(tempDir.resolve("logs"));
    Files.createSymbolicLink(baseDir.resolve("app-2.log"), outsider);

    final Configuration config = new BasicConfigurationFactory().new BasicConfiguration();
    final PosixViewAttributeAction action = PosixViewAttributeAction.newBuilder()
            .setBasePath(baseDir.toString())
            .setFollowLinks(true)
            .setMaxDepth(1)
            .setPathConditions(PathCondition.EMPTY_ARRAY)
            .setConfiguration(config)
            .setFilePermissionsString("rw-rw-rw-")
            .build();

    action.execute();

    assertEquals(
            "rw-rw-rw-",
            PosixFilePermissions.toString(Files.getPosixFilePermissions(outsider)),
            "followLinks=\"true\" should still follow the link");
}

[ramanathan1504]

Deletion block for the old test:

Suggested change

@Test

[ramanathan1504]

Could the entry say which configuration changes? As written, a reader with links in their log directory cannot tell whether this affects them.

Suggested change

	<description format="asciidoc">Stop `PosixViewAttribute` from applying permissions and ownership through symbolic links</description>
	<description format="asciidoc">Stop `PosixViewAttribute` from applying permissions and ownership through symbolic links found in `basePath` unless `followLinks` is set to `true`.</description>