Hi
I have a situation where i need to blanketly allow read permissions on /opt to any user at all.
I have some bad behaving apps though that seem to overwrite these permissions and do not set world read on their log directories.
Is there any way i can make /opt world readable and make sure these permissions stick to all subfolders and not allow users other than root/sudo to change them?
thanks
Is there any way i can make /opt world readable and make sure these permissions stick to all subfolders and not allow users other than root/sudo to change them?
Make it a seperate filesystem mounted read-only, then remount it rw when you need to make changes.
Is there any way i can make /opt world readable and make sure these permissions stick to all subfolders and not allow users other than root/sudo to change them?
Make it a seperate filesystem mounted read-only, then remount it rw when you need to make changes.
i cant as the applications need to log there - i just need 'everyone' to be able to read there - i would have thought i could somehow stick the read permissions but it seems that perhaps not.
On Tue, Jul 22, 2008 at 9:55 AM, Tom Brown tom@ng23.net wrote:
Is there any way i can make /opt world readable and make sure these permissions stick to all subfolders and not allow users other than root/sudo to change them?
Make it a seperate filesystem mounted read-only, then remount it rw when you need to make changes.
i cant as the applications need to log there - i just need 'everyone' to be able to read there - i would have thought i could somehow stick the read permissions but it seems that perhaps not.
What are the applications? What is the directory structure? Is the permission problem on a directory or a file? What user account owns the application process? Is the app un-doing your manual permission changes on existing files and directories, or just not granting read permission to new objects?
If an application so chooses, it can set whatever permissions it wants on newly created files. It may even have logic to alter the permissions on existing files. You may not be able to control it from the OS level.
Or, it could be as simple as setting (or changing) the umask in the application startup script.
What are the applications? What is the directory structure? Is the permission problem on a directory or a file? What user account owns the application process? Is the app un-doing your manual permission changes on existing files and directories, or just not granting read permission to new objects?
in house apps running out of /opt/<appname> and logging into /opt/<appname>/logs and are running as user <appname>
need to have world read on /opt/<appname>/logs
when permissions are 'manually' set when the app is redeployed it seems that the world read is removed (i am investigating why this is)
If an application so chooses, it can set whatever permissions it wants on newly created files. It may even have logic to alter the permissions on existing files. You may not be able to control it from the OS level.
Or, it could be as simple as setting (or changing) the umask in the application startup script.
i was hoping at the OS level i could limit what the app could do with the permissions as the app is not running as root. it seems i cant do that so i will need to look at how the app is deployed and why the perms are being reset/overwritten.
On Tue, 2008-07-22 at 15:55 +0100, Tom Brown wrote:
Is there any way i can make /opt world readable and make sure these permissions stick to all subfolders and not allow users other than root/sudo to change them?
Make it a seperate filesystem mounted read-only, then remount it rw when you need to make changes.
i cant as the applications need to log there - i just need 'everyone' to be able to read there - i would have thought i could somehow stick the read permissions but it seems that perhaps not.
The only possibilities I see quickly are using chattr and/or acl lists (seems more promising, but not sure as I didn't take the time to really understand the *implied* results).
$ man -k acl acl (5) - Access Control Lists acl (rpm) - Access control list utilities. chacl (1) - change the access control list of a file or directory getfacl (1) - get file access control lists libacl (rpm) - Dynamic library for access control list support. setfacl (1) - set file access control lists
"man chattr".
A *brief* scan doesn't yield an obvious simple solution though. But as mentioned, there may be some implications that might "git 'er done".
<snip>
HTH
-
Jeff -
Stephen Harris -
Tom Brown -
William L. Maltby