- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: DNS$MSG.EXE protection
Operating System - OpenVMS
1752800
Members
5394
Online
108789
Solutions
Forums
Categories
Company
Local Language
юдл
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
юдл
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-21-2006 05:49 AM
тАО08-21-2006 05:49 AM
DNS$MSG.EXE protection
Someone noticed that SYS$MESSAGE:DNS$MSG.EXE doesn't have W:RE protection. (World has NO access). All the other EXE files in SYS$MESSAGE have W:RE access. Does anyone know why? Is this on purpose?
3 REPLIES 3
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-21-2006 09:29 AM
тАО08-21-2006 09:29 AM
Re: DNS$MSG.EXE protection
I have two:
DNS$MSG.EXE;1 (RWED,RWED,RE,)
DNS$MSG_VMS.EXE;1 (RWED,RWED,RE,)
but there's a similar-looking:
DNS$MSG_V.EXE;1 (RWED,RWED,RE,RE)
Looks to me like an error.
A bunch of mine have G:REWD, too, but most
are G:RE.
DNS$MSG.EXE;1 (RWED,RWED,RE,)
DNS$MSG_VMS.EXE;1 (RWED,RWED,RE,)
but there's a similar-looking:
DNS$MSG_V.EXE;1 (RWED,RWED,RE,RE)
Looks to me like an error.
A bunch of mine have G:REWD, too, but most
are G:RE.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-21-2006 04:09 PM
тАО08-21-2006 04:09 PM
Re: DNS$MSG.EXE protection
Thomas,
It might be an oversight. On my V6.2 systems, the protection is W:RE, but on later versions it's W(none).
I guess it depends on what images are intended to use the message file. If they're all installed, privileged images, or they're intended to be used only by privileged users, then the security may be deliberate, or may not be relevant.
A quick look at a V8.2 system disk, it appears DNS$MSG is referenced from NET$EVENT_DISPATCHER, NCLSHR, NET$EVD_RELAY_FORMATTER and DNS$MSG_V. I can't imagine joe-unprivileged-user messing with any of them.
On one hand, it probably doesn't matter if you open W:RE access to the message file, but on the other, what's broke that you think you're fixing?
If your users aren't complaining about failure to translate DNS messages, it might be better to just leave it be. If you have file access failure auditing enabled, you'll now quickly enough if anyone who should have access is being denied.
It might be an oversight. On my V6.2 systems, the protection is W:RE, but on later versions it's W(none).
I guess it depends on what images are intended to use the message file. If they're all installed, privileged images, or they're intended to be used only by privileged users, then the security may be deliberate, or may not be relevant.
A quick look at a V8.2 system disk, it appears DNS$MSG is referenced from NET$EVENT_DISPATCHER, NCLSHR, NET$EVD_RELAY_FORMATTER and DNS$MSG_V. I can't imagine joe-unprivileged-user messing with any of them.
On one hand, it probably doesn't matter if you open W:RE access to the message file, but on the other, what's broke that you think you're fixing?
If your users aren't complaining about failure to translate DNS messages, it might be better to just leave it be. If you have file access failure auditing enabled, you'll now quickly enough if anyone who should have access is being denied.
A crucible of informative mistakes
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-21-2006 04:21 PM
тАО08-21-2006 04:21 PM
Re: DNS$MSG.EXE protection
I don't know about anyone else, but I have a
procedure which tries to get the message text
for a status code, and when it gets "NOMSG",
it tries to "set message" on each of the
files in sys$message until it gets a good
message (or runs out of files).
Anyone, privileged or not, might wish to
translate such an error code, but it won't
work well if he can't read the file.
The probability of anyone actually caring may
be fairly small, but I estimate the
probability of W:RE on any of these files
being wrong enough to cause trouble to be
_vanishingly_ small.
I'd vote for setting all of them the same,
and then waiting for a disaster. I'd expect
to be waiting a very long time.
procedure which tries to get the message text
for a status code, and when it gets "NOMSG",
it tries to "set message" on each of the
files in sys$message until it gets a good
message (or runs out of files).
Anyone, privileged or not, might wish to
translate such an error code, but it won't
work well if he can't read the file.
The probability of anyone actually caring may
be fairly small, but I estimate the
probability of W:RE on any of these files
being wrong enough to cause trouble to be
_vanishingly_ small.
I'd vote for setting all of them the same,
and then waiting for a disaster. I'd expect
to be waiting a very long time.
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
News and Events
Support
© Copyright 2024 Hewlett Packard Enterprise Development LP