Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230
Modifying readonly files
Modifying readonly files
I want to modify readonly files (such as, config files in /etc directory), I know I can do it manually with sudo vi command, however, I want to do it through coding, such as a .Net core application has to modify some readonly config files. since these config files has read/write permissions only for root user, while for group and others has only read access. My application code modifies these files only when I explicitly change the permissions on these files to read/write for group and others. Is it possible to mount the file system (root partion) temperary to read/write and modify these files and then change the file system back to readonly?? Please suggest me any other better way, except for changing the permission on individual files or changing owner.
-
- df -h | grep > 20TiB
- Posts: 1400
- Joined: 2012-10-06 05:31
- Location: /dev/chair
- Has thanked: 79 times
- Been thanked: 175 times
Re: Modifying readonly files
Eh? How does that even remotely help when you want to modify system-wide configuration in /etc?
ro/rw on the mount has nothing to do with file permissions.
It's extremely unlikely that your root file system is mounted read-only to begin with, and even if you were to do a remount -o rw, that still won't change file ownership.
I don't do (or want anything to do with) .NET, but the laziest option that occurs to me is to just call an external binary to handle privilege escalation when you need to write out a file, and the simplest candidate for that would probably be pkexec since it should use the best authentication prompt mechanism available on the system.
If you need to do the same without a prompt, you could drop the relevant config into a file in /etc/polkit-1/rules.d/ at install / first-run time. The usual caveats about not creating gaping security holes of course apply.
Ideally you'd do this all within your application, either with polkit directly or via dbus calls. A quick google search suggests dbus bindings might exist for .net core (I'm not going to look harder than that, it's .net), so that might be the "best" option.
The wiki has more information on policykit, as well as links to the API docs.
Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy.
-
- df -h | grep > 20TiB
- Posts: 1400
- Joined: 2012-10-06 05:31
- Location: /dev/chair
- Has thanked: 79 times
- Been thanked: 175 times
Re: Modifying readonly files
If you're suggesting replacing a system-wide root-owned configuration file in /etc/ with a symlink to a file in somebody's home directory... *shudder*.
I mentioned gaping security holes already, right? Should I mention multi-user system architecture as well? Things in /etc/ are owned by root specifically so that random users can't modify them.
If that configuration file is sourced by a shell interpreter anywhere (and many things in /etc/ are), you've just created an instant trojan that allows an unprivileged user to run arbitrary commands as root.
Obvious security implications aside, from a purely functional point of view this would also mean that one user and one user only now has control over system-wide configuration...
What if there is more than one user on the system? Should we link protected configuration files into /tmp/ instead and allow any tom, ****, or harry to mess with them?
OTOH, If I have the wrong end of the stick on what you're suggesting... Then I'm sorry, but I'm still lost as to how it helps.
Last edited by steve_v on 2021-08-30 23:17, edited 1 time in total.
Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy.
-
- Global Moderator
- Posts: 2636
- Joined: 2018-06-20 15:16
- Location: Colorado
- Has thanked: 41 times
- Been thanked: 192 times
Re: Modifying readonly files
Since the file in question is not specified, what changes are made, and what else might like to edit or upgrade the file, who uses the computer, I don't need to care. The OP can make the determination.
The implications and complications should be obvious. I use the method, still can't imagine an issue.
-
- df -h | grep > 20TiB
- Posts: 1400
- Joined: 2012-10-06 05:31
- Location: /dev/chair
- Has thanked: 79 times
- Been thanked: 175 times
Re: Modifying readonly files
You do you of course, but telling someone to throw out privilege-separation, multi-user functionality, and elementary *nix security principles when they may well be writing an application for dissemination to the general public is pretty bad form.
Especially when you don't know what files they're working with. What if it's /etc/shadow? or /etc/profile? Can you not "imagine an issue" with a normal user being able to clear root's password, or add random aliases to root's shell environment?
What if it's a configuration file the system needs to boot, and /home is on a separate partition? You've just bricked someone's box.
Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy.
-
- Global Moderator
- Posts: 2636
- Joined: 2018-06-20 15:16
- Location: Colorado
- Has thanked: 41 times
- Been thanked: 192 times
Re: Modifying readonly files
Wow, take a pill.
How about we wait for the OP. I choose to assume some intelligence, or maybe clarification...
I don't 'what if' with incomplete info.
...where appropriate. It violates none of the magic you mention.
-
- df -h | grep > 20TiB
- Posts: 1400
- Joined: 2012-10-06 05:31
- Location: /dev/chair
- Has thanked: 79 times
- Been thanked: 175 times
Re: Modifying readonly files
That's my point. It might be appropriate for you, on your single-user home desktop. Telling someone else to do it without even the due diligence of explaining the pitfalls is not appropriate at all.
This scenario is precisely why tools like sudo, doas, and polkit exist in the first place. If files in /etc/ were meant to be modified without access controls, they wouldn't be in /etc/.
I'm not going to argue with you further. Handing someone a loaded footgun when you have no idea what their skill-level is or what they're planning to do with it is simply a bad idea from any angle.
Besides, to quote from the OP:
Moving the file to /home and changing the permissions there is still changing the permissions, something explicitly not asked for.except for changing the permission on individual files or changing owner.
Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy.
-
- Global Moderator
- Posts: 2636
- Joined: 2018-06-20 15:16
- Location: Colorado
- Has thanked: 41 times
- Been thanked: 192 times
Re: Modifying readonly files
Well, typical, missing OP.
So what...? You don't consider that could be the point?functional point of view this would also mean that one user and one user only now has control over system-wide configuration..
..and on your mission control center any yahoo with the password can mod the system, nice.It might be appropriate for you, on your single-user home desktop
How do you think this is done? Dozens of things in /etc/ are created by *ME*, as a user. I happen to be root's Boss. In ALL of those cases the file is of purpose where 'random' code does no more than the same in a file carefully and dutifully modified with your password in vim...NONE of the files are ever written to by anything. They simply need read, and by who/what?...this is the point.polkit exist in the first place. If files in /etc/ were meant to be modified without access controls, they wouldn't be in /etc/.
Indeed, with my points above, my offer is the file ownership may in fact -not be important. So, consider it. Maybe the ownership would not switch back and forth, because it doesn't matter...Moving the file to /home and changing the permissions there is still changing the permissions, something explicitly not asked for.
...ridiculous.you've just created an instant trojan that allows an unprivileged user to run arbitrary commands as root.
Since you introduce the straw man 'normal user', I'll answer *MY* user can certainly change your password, and root's.Can you not "imagine an issue" with a normal user being able to clear root's password