nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

OD Manifests world writable ?

nipper

TS 7.3.1, OD, LSDS/LSCS on Linux. OD installed as root, system umask is a normal 022.

Customer complains that the OD manifests for the LiveSite/ExtendedAttributeContentMetadata deployments have permissions of rw-rw-rw:

-rw-rw-rw- 1 root root 0 Sep 14 11:29 src.ExtendedAttributeContentMetadatah6zmgasxh6zmgat4.ExtendedAttributeContentMetadata.www-cmt-01.to.database.log.mf

While the logs are rw-r--r--
-rw-r--r-- 1 root root 49220 Sep 14 11:29 src.ExtendedAttributeContentMetadatah6zmgasxh6zmgat4.ExtendedAttributeContentMetadata.www-cmt-01.to.database.log

I have not been able to figure out a way to prevent that. Tried the group sticky bit but that is only for owner/group.

I checked another former customer and noticed the same thing. There was a thread from before, but no resolution.

Anyone find a way to fix this ? Security is not happy. I have a support call open.

Find more posts tagged with

Comments

Rick Poulin

Java up to and including 6 is not aware of file permissions. Only Java7 has kind of introduced an API for this, and it's not perfect, but that doesn't help your current build anyway.

The point is, whether iwov is creating the file via FileOutputStream or File.createNewFile() or whatever, it'll always use whatever permissions are granted by your system by default. If your admins know of a way to set the defaults for iwui to be 644 for *every* file it writes, then maybe you have a leg to stand on. Iwov certainly won't be able to help you, because Java(6) itself doesn't support it.

At best, they'd have to give you a nasty patch that, for 'nix systems, forks an local exec to chmod. They might do it for this one instance, but there's no way in **** they're going to go through the entire code base to do this. There will be other files writable by world, I can guarantee you that. If your sysadmins can't set a default perms at the OS level, then they'll just have to suck it up as a product (if not programming language) limitation.

Adam Stoller

TS 7.3.1, OD, LSDS/LSCS on Linux. OD installed as root, system umask is a normal 022. [...].

It sounds like some process is running under a umask of 000 rather than root's 022.

Though perhaps rpoulin's information about it being a Java quirk might be the source of the issue. Let us know if/when you get an update from Support.

nipper

It sounds like some process is running under a umask of 000 rather than root's 022.

Though perhaps rpoulin's information about it being a Java quirk might be the source of the issue. Let us know if/when you get an update from Support.

Yea that was my first thought, but they run with a very restrictive umask (077) for root (that makes things extremely tough).

Also log files are set correctly (rw-r--r--) which is what the manual says they should be. Strange that a log for deployment foo has those permission but a manifest generated at the same time does not.

Rick Poulin

I can only comment on the Java side of things.. I believe OD uses log4j internally for the logging, and that framework might've found an answer to respect the OS mask. All I can say for sure is that this gets messy and hard to control in Java without specifically coding in native workarounds.

Adam Stoller

As a fall-back-and-punt workaround option - create a cron job (or monitoring process) that looks for files in the ODHOME/log directory tree that have the wrong permissions and fix them.

It doesn't solve the problem, but it masks (pun slightly intended) the symptoms..

nipper

Yea basically hide from the security scans. We opened a support case.