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

If none of the specific sub-forums seem right for your thread, ask here.
Post Reply
Message
Author
preetjt
Posts: 1
Joined: 2021-08-30 20:43

Modifying readonly files

#1 Post by preetjt »

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.

CwF
Global Moderator
Global Moderator
Posts: 2638
Joined: 2018-06-20 15:16
Location: Colorado
Has thanked: 41 times
Been thanked: 192 times

Re: Modifying readonly files

#2 Post by CwF »

Link the file to a user space location, ~/home/.something, and modify this file instead.

steve_v
df -h | grep > 20TiB
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

#3 Post by steve_v »

CwF wrote: 2021-08-30 22:25Link the file to a user space location, ~/home/.something, and modify this file instead.
Eh? How does that even remotely help when you want to modify system-wide configuration in /etc?

preetjt wrote: 2021-08-30 21:13 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??
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.
preetjt wrote: 2021-08-30 21:13Please suggest me any other better way, except for changing the permission on individual files or changing owner.
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.

CwF
Global Moderator
Global Moderator
Posts: 2638
Joined: 2018-06-20 15:16
Location: Colorado
Has thanked: 41 times
Been thanked: 192 times

Re: Modifying readonly files

#4 Post by CwF »

steve_v wrote: 2021-08-30 22:33Eh?
File exist in user space, modify it, save it...that's how. /etc/somthing is a link...

steve_v
df -h | grep > 20TiB
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

#5 Post by steve_v »

CwF wrote: 2021-08-30 22:53/etc/somthing is a link...
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.

CwF
Global Moderator
Global Moderator
Posts: 2638
Joined: 2018-06-20 15:16
Location: Colorado
Has thanked: 41 times
Been thanked: 192 times

Re: Modifying readonly files

#6 Post by CwF »

steve_v wrote: 2021-08-30 23:04
CwF wrote: 2021-08-30 22:53/etc/somthing is a link...
*shudder*
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.

steve_v
df -h | grep > 20TiB
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

#7 Post by steve_v »

CwF wrote: 2021-08-30 23:15I use the method, still can't imagine an issue.
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.

CwF
Global Moderator
Global Moderator
Posts: 2638
Joined: 2018-06-20 15:16
Location: Colorado
Has thanked: 41 times
Been thanked: 192 times

Re: Modifying readonly files

#8 Post by CwF »

Wow, take a pill.
steve_v wrote: 2021-08-30 23:30 You've just bricked someone's box.
How about we wait for the OP. I choose to assume some intelligence, or maybe clarification...
steve_v wrote: 2021-08-30 23:30What if
I don't 'what if' with incomplete info.
CwF wrote: 2021-08-30 23:15 . I use the method,
...where appropriate. It violates none of the magic you mention.

steve_v
df -h | grep > 20TiB
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

#9 Post by steve_v »

CwF wrote: 2021-08-31 00:12where appropriate
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:
except for changing the permission on individual files or changing owner.
Moving the file to /home and changing the permissions there is still changing the permissions, something explicitly not asked for.
Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy.

CwF
Global Moderator
Global Moderator
Posts: 2638
Joined: 2018-06-20 15:16
Location: Colorado
Has thanked: 41 times
Been thanked: 192 times

Re: Modifying readonly files

#10 Post by CwF »

Well, typical, missing OP.
functional point of view this would also mean that one user and one user only now has control over system-wide configuration..
So what...? You don't consider that could be the point?
It might be appropriate for you, on your single-user home desktop
..and on your mission control center any yahoo with the password can mod the system, nice.
polkit exist in the first place. If files in /etc/ were meant to be modified without access controls, they wouldn't be in /etc/.
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.
Moving the file to /home and changing the permissions there is still changing the permissions, something explicitly not asked for.
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...
you've just created an instant trojan that allows an unprivileged user to run arbitrary commands as root.
...ridiculous.
Can you not "imagine an issue" with a normal user being able to clear root's password
Since you introduce the straw man 'normal user', I'll answer *MY* user can certainly change your password, and root's.
steve_v wrote: 2021-08-31 00:41 That's my point.

Post Reply