Hello,
It is Solaris-10. There is a file as /opt/vpp/dom1.2/pdd/today_23. It is always generated by root, so owned by root only.
This file has to be deleted as part of application restart always and that is done by app_user and SA is always involved to do rm on that file.
Is it possible to give rm access to app_user, only to that file, via sudoers ? So that, he can delete only that file, not any other path or file or folder.
Regards
Why do you not change the app running as root to chmod/chown permissions required to allow the correct user to delete the file? Or have the app run by the user to start with?
This application should not run as root.
If application team needs to restart their application, they are required to remove file /opt/vpp/dom1.2/pdd/today_23 or else application will not start clean. And this file is owned by root always. app_user should be eligible so restart this application, so I have already given start/stop sudo access to app_user, but not sure how should I give rm access only for that specific file.
You're missing the point.
We understand that your application should not run as root. What Jim suggested is that the other application that is creating a file owned by root should change the owner of the file that you want your application to remove to be app_user; not root. If a user needs to be able to remove a file, that user needs to have appropriate permissions to remove that file. If a user named app_user needs to be able to remove a file, there is no reason why a user named root needs to own that file.
I got the point. It may be nature of application, the way it is creating file with root ownership. I can check with application owner, if this nature can be changed.
But, is it possible at all, to give sudo access to app_user to remove that root owned file ? I just want to have my statement correct, before jumping into discussion with them.
I agree that the process that creates the file needs to be looked at first.
Do you have write access to the directory that this file is in? If so, can you not remove the file anyway? (or is the sticky bit set?)
If the file has to be removed, your application must be able to create a replacement else
There are certainly several ways to grant a remove privilege, but that's probably not the best way to do it.
Probably the worst approach to fixing a problem is writing more code to paper over the symptom of the problem instead of just fixing the actual problem.
Your problem here is a file has ownership/permissions that prevent processing per your system's requirements.
Instead of fixing that problem, your proposed solution is to write even more code and/or create something new in order to change the symptom.
So instead of a fixed problem, you now have a problem, a patch that hides that problem, an entire set of undocumented dependencies for working around that problem, and a requirement to spend future resources keeping that patch working.
Ever wonder how computer systems get unreliable?
That's exactly how.
Do you want reliable systems?
FIX the actual problems, never ADD extras to patch over and hide them.
I'm willing to bet that when you come back with why the file is written by root it is because the directory /opt/vpp/dom1.2/pdd is owned by root.
Consider this:
dewi(6)$ file xyzzy
xyzzy: cannot open `xyzzy' (No such file or directory)
dewi(7)$ sudo touch xyzzy
[sudo] password for apm:
dewi(8)$ ls -l xyzzy
-rw-r--r-- 1 root root 0 24 Aug 11:29 xyzzy
dewi(9)$ rm xyzzy
rm: remove write-protected regular empty file 'xyzzy'? y
dewi(10)$ ls -l xyzzy
ls: cannot access 'xyzzy': No such file or directory
dewi(11)$ sudo mkdir XYZZY
dewi(12)$ ls -ld XYZZY/
drwxr-xr-x 2 root root 4096 24 Aug 11:31 XYZZY/
dewi(13)$ cd XYZZY/
dewi(14)$ sudo touch xyzzy
dewi(15)$ ls -la
total 8
drwxr-xr-x 2 root root 4096 24 Aug 11:32 .
drwxr-xr-x 19 apm sog 4096 24 Aug 11:31 ..
-rw-r--r-- 1 root root 0 24 Aug 11:32 xyzzy
dewi(16)$ rm -f xyzzy
rm: cannot remove 'xyzzy': Permission denied
dewi(17)$
So because I own the parent directory I was able to deleted the first xyzzy file, but because root owned the directory XYZZY I was unable to delete the second xyzzy file.
So why does the file today_23 need to be created in the directory /opt/vpp/dom1.2/pdd ? Can it be created elsewhere? Failing that, could the directory pdd be modified to give the user the required write permission to create and delete the file without root access?
Andrew
In fact it is possible to set such a sudo -rule. Put the follwoing in /etc/sudoers :
username ALL=(ALL:ALL) NOPASSWD: /path/to/rm /path/to/file
PLEASE NOTICE, though, this does not invalidate what my colleagues have already said about problems, symptoms and patching over them. I just want to tell you that - if every other way of correcting the underlying problem fails - there is a last-ditch solution you could employ. You still should try your utmost to avoid needing that. See also here, which is basically the same principle at work.
I hope this helps.
bakunin
Thanks much.
But as you and other suggested, I will try to fix ownership issue with app team, then we may not need to tweek sudoers