General discussion of protected file editing, not a need for help.

[gsparky2004]

Just let me start by saying I don't need technical help. I'm looking for a discussion and comments.

I just finished a short "help me" thread on editing the grub.cfg file. The first reply I received simply pointed out the first few lines of that file (grub.cfg) which states:

#
# DO NOT EDIT THIS FILE
#

First, I was frustrated that I couldn't edit the file, even though I was using:

sudo gedit grub.cfg

What I received when I tried to save the file was a message saying it was in a write-protected disk and I couldn't save it.

Second, I thought this went against the concept of Linux, meaning the user has total control. Am I reading this wrong? Yes, it's possible that I might screw up the file. But that's the point of Linux. You make a mistake (perhaps a really big one), but then you learn from that.

[cariboo]

The messages you got just means, that you don't know enough to screw up your system yet . Just because you tried to edit the file as root, and it wouldn't let you save your changes, doesn't mean it is impossible to do so. I would suggest you learn about permissions and give it a try again.

[Sarmacid]

Yes, it's a simple matter of permissions. However the grub.cfg file gives you alternatives in case you really want to change it's behaviour.

# DO NOT EDIT THIS FILE
#
# It is automatically generated by /usr/sbin/grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub

[sisco311]

Second, I thought this went against the concept of Linux, meaning the user has total control. Am I reading this wrong? Yes, it's possible that I might screw up the file. But that's the point of Linux. You make a mistake (perhaps a really big one), but then you learn from that.

Root has total control. You have to choose the right tool for the job.

[bodhi.zazen]

Just let me start by saying I don't need technical help. I'm looking for a discussion and comments.

I just finished a short "help me" thread on editing the grub.cfg file. The first reply I received simply pointed out the first few lines of that file (grub.cfg) which states:

#
# DO NOT EDIT THIS FILE
#

First, I was frustrated that I couldn't edit the file, even though I was using:

sudo gedit grub.cfg

What I received when I tried to save the file was a message saying it was in a write-protected disk and I couldn't save it.

Second, I thought this went against the concept of Linux, meaning the user has total control. Am I reading this wrong? Yes, it's possible that I might screw up the file. But that's the point of Linux. You make a mistake (perhaps a really big one), but then you learn from that.

You should use gksu with graphical apps such as gedit

The second issue is "security", it is a feature.

[Agent ME]

You can't edit grub.cfg because it doesn't have write permission set. You can set write permission on it with root, but there's a reason it's set this way. Grub.cfg is regenerated using data from many extra config files every time the system is updated. If you put your changes straight into grub.cfg, they'll just be lost on the next update. You need to put your changes into the files that are used to generate grub.cfg in the first place.

You should use gksu with graphical apps such as gedit

If you're already in a terminal, sudo works just as well. Gksu was made for those situations you're not already on a command line, and there is no standard input to read from (like for menu shortcuts). Actually, if you're in a terminal and launching a graphical program, I'd recommend using sudo with the -b option ("sudo -b gedit"), which backgrounds the launched task so you can continue using the terminal after the task is started.

[lswb]

You could not edit the file with gedit because by design, it is difficult to hose your system with a gui tool. You need the cli for that!

[lswb]

...
If you're already in a terminal, sudo works just as well. Gksu was made for those situations you're not already on a command line...

gksudo (or gksu) is recommended (rather than sudo) to run a gui program as root regardless of whether it is started in a terminal or not. One reason being that using sudo instead makes it easier to inadvertently give root ownership to files in your home directory.

[Agent ME]

gksudo (or gksu) is recommended (rather than sudo) to run a gui program as root regardless of whether it is started in a terminal or not. One reason being that using sudo instead makes it easier to inadvertently give root ownership to files in your home directory.

From the man page for gksu, it looks like it uses the same mechanism as su/sudo for elevating privileges.

And I just did a quick test. "sudo -b xterm","touch test-sudo" and "gksu xterm &","touch test-gksu" both create the the file owned by root inside my home directory. I can't find any difference between su/sudo and gksu/gksudo besides different options that can be passed on the command line. They also start xterm with identical environment variables.

[sisco311]

From the man page for gksu, it looks like it uses the same mechanism as su/sudo for elevating privileges.

And I just did a quick test. "sudo -b xterm","touch test-sudo" and "gksu xterm &","touch test-gksu" both create the the file owned by root inside my home directory. I can't find any difference between su/sudo and gksu/gksudo besides different options that can be passed on the command line. They also start xterm with identical environment variables.

http://psychocats.net/ubuntu/graphicalsudo

man gksu

 --preserve-env, -k

              Preserve the current environments, does not set $HOME nor $PATH,
              for example.

--preserve-env is not default, that means that gksu resets the $HOME environment by default while sudo doesn't.

sudo gnome-terminal

then run:

echo $HOME

and

gksu gnome-terminal

then run:

echo $HOME