Avatar

Please consider registering
guest

sp_LogInOut Log In sp_Registration Register

Register | Lost password?
sp_Search Search
Advanced Search
Advanced Search

— Forum Scope —




— Match —





— Forum Options —





Minimum search word length is 3 characters - maximum search word length is 84 characters

sp_Search Search
Go to Bottom
No permission to create posts
sp_Feed Topic RSS sp_TopicIcon
ApplicationIdentity.setApplicationDescription causes a Permission issue.
November 22, 2024
20:10, EET
Avatar
mithun
Member
Members
Forum Posts: 8
Member Since:
September 11, 2024
sp_UserOfflineSmall Offline
Go to Top
1sp_Permalink sp_Print

Hello,

I implement an OPC UA server using the java sdk and in my server (which runs in a controlled enviroment) durin initialize, I do a ApplicationDescription.setApplicationUrl with my hostname. Unfortunately, some users do not have a domain name set up and their fully qualified host name is only a host name (example “BestHostName”).

This triggers a registry call (“reg query HKLM\\SYSTEM\\CurrentControlSet\\Services\\Tcpip\\Parameters /v Domain”) in OSUtil.windowsRegistryDomainNameOutput.

This happens as in ApplicationIdentity.replaceHostNameTagWithActualHostName, the sdk performs a String replace with getActualHostName() without checking if the host name given is valid or not.

This is my actual exception:

java.security.AccessControlException: access denied (“java.io.FilePermission” “<>” “execute”)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
at java.security.AccessController.checkPermission(AccessController.java:886)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at java.lang.SecurityManager.checkExec(SecurityManager.java:799)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1018)
at java.lang.Runtime.exec(Runtime.java:594)
at java.lang.Runtime.exec(Runtime.java:424)
at java.lang.Runtime.exec(Runtime.java:321)
at com.prosysopc.ua.stack.utils.OSUtil.exec(SourceFile:102)
at com.prosysopc.ua.stack.utils.OSUtil.exec(SourceFile:78)
at com.prosysopc.ua.stack.utils.OSUtil.etO(SourceFile:399)
at com.prosysopc.ua.stack.utils.OSUtil.etN(SourceFile:390)
at com.prosysopc.ua.stack.utils.OSUtil.getDomainNameFromOs(SourceFile:152)
at com.prosysopc.ua.stack.utils.OSUtil.getHostNameWithDomain(SourceFile:177)
at com.prosysopc.ua.ApplicationIdentity.getActualHostName(SourceFile:426)
at com.prosysopc.ua.ApplicationIdentity.replaceHostNameTagWithActualHostName(SourceFile:1114)
at com.prosysopc.ua.ApplicationIdentity.a(SourceFile:1164)
at com.prosysopc.ua.ApplicationIdentity.setApplicationDescription(SourceFile:1566)
at com.prosysopc.ua.ApplicationIdentity.setApplicationDescription(SourceFile:1551)
at com.tridium.opcUaServer.BOpcUaServer.lambda$initialize$3(BOpcUaServer.java:1061)
at java.security.AccessController.doPrivileged(Native Method)

November 25, 2024
11:38, EET
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 1028
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline
Go to Top
2sp_EditHistory sp_Permalink sp_Print

Hi,

That ‘OSUtil’ is a fallback scenario (at least currently) in case the FQN hostname we find is one of the ApplicationIdentity.getBannedHostnames(). That by default that has only a single entry “host.docker.internal”. If that happens, the Docker installation on the machine has prevented us from performing a proper reverse-DNS on the hostname to resolve the FQN version of it (i.e. Docker installation modified the ‘hosts’ file). Thus we try some OS-spesific ways to resolve it via java.lang.Runtime.exec(String[]). This issue shouldn’t happen if Docker not installed.

The stacktrace contains ‘SecurityManager’ and seems that part fails. That would imply that a SecurityManager has been enabled in the environment. Generally speaking, it is typically never ever enabled ( and is to be removed in https://openjdk.org/jeps/486 i.e. in Java 24 and was already deprecated in 17; basically it was mostly used for Applets). Thus ‘a solution’ would be to just disable it. That being said, since it isn’t by default enabled, that might not be an option since for some reason it has been turned on.

Probably the SDK should be improved to catch that exception at least, but there is basically no other way that we know to go outside of Java itself if that situation with “host.docker.internal” happens. Maybe in this case it should then use the non-fqn version instead.

If you “magically know” the hostname, you can use the static com.prosysopc.ua.ApplicationIdentity.setActualHostName(String) before other interactions to override the hostname (this sets the value ApplicationIdentity.setCacheLocalHostname(boolean) uses and by default that is true, thus you pre-set the cached hostname thus no lookup is performed, thus it wont go to the “host.docker.internal” fallback logic).

There potentially could be ways to edit the hosts file to avoid this issue, but that might cause some issues for Docker-related applications.

P.S.
You shouldn’t leave the hostname as “host.docker.internal”, as it can cause issues for some clients that expect that to be the address they used to connect to the server. That is also the reason we try to find the FQN version if possible, since that solves most of those problems.

No permission to create posts
sp_Feed All RSS
Go to top
Forum Timezone: Europe/Helsinki

Most Users Ever Online: 1919

Currently Online:
11 Guest(s)

Currently Browsing this Page:
1 Guest(s)

Top Posters:

Heikki Tahvanainen: 402

hbrackel: 144

rocket science: 88

pramanj: 86

Francesco Zambon: 83

Ibrahim: 78

Sabari: 62

kapsl: 57

gjevremovic: 49

Xavier: 43

Member Stats:

Guest Posters: 0

Members: 724

Moderators: 7

Admins: 1

Forum Stats:

Groups: 3

Forums: 15

Topics: 1526

Posts: 6457

Newest Members:

forrestdilke5, ernestoportus31, martin123, rickie5305, shaylamaggard4, rickyjuarez140, jonathonmcintyre, fannielima, kristiewinkle8, rust

Moderators: Jouni Aro: 1026, Pyry: 1, Petri: 0, Bjarne Boström: 1028, Jimmy Ni: 26, Matti Siponen: 346, Lusetti: 0

Administrators: admin: 1