Tiny Core Linux
General TC => General TC Talk => Topic started by: jpeters on January 26, 2009, 09:40:53 PM
-
I would like to have a dime for every time I have typed "sudo" in the last two weeks.....and yet I still frequently forget to type it yet once again. This generally happens before I do a long edit using vi, and then try to save it. I sure am greatful for all the protection against myself, but wonder if it isnt adding to rapid onset dementia.
-
If you're using full vim, you can use ":w /path/to/filename"
In busybox's vi, you need to manually override the read-only, ie ":w! /path/to/filename"
-
If you're using full vim, you can use ":w /path/to/filename"
In busybox's vi, you need to manually override the read-only, ie ":w! /path/to/filename"
The problem is one of permissions, in which case w! doesn't work for either vim or vi. (ie.,root:root)
It seems that after losing a few edits by not using "sudo vi", I begin to use "sudo" for everything...including writing the initial file. (i.e., sudo vi /dir/new_file) or even "sudo mkdir". Now everything is root:root, and if I fail to use "sudo" when editing, I lose it. This serves to once again increase my use of "sudo" for everything....since then I never have to know what the underlying permissions are for the file I just opened.
It gets further complicated if I write a new file without sudo within a root:staff or root:root folder. Now I can't save what I wrote, because I would have had to initiate the new file with "sudo'. Once again, I start using
sudo for everything. :(
EDIT: the work around, of course, is to change the permissions from the terminal,,,which allows
me to save what I wrote. Chown is fast becoming one of my other favorite words. (( finally figured this out after rewriting edits several times). Other incentives for "sudo" include trying to remove a folder without it, and having to go through a questionaire regarding every file inside it. "Sudo" effectively dumps the whole thing instantly....and I'm hooked!
-
..."Sudo" effectively dumps the whole thing instantly....and I'm hooked!
How does that saying go - "don't take the name root in vain..." :)
-
The problem is one of permissions, in which case w! doesn't work for either vim or vi. (ie.,root:root)
I think what he meant by ":w /path/to/filename" was to use a different, writable path. Then, as root, move the new file over the old & change its ownership back to root. It's still an inconvenience, but at least you keep your edits.
Simple rule: For anything outside of /home/tc, be root.
My preferred practice is to start a root terminal if I plan to do any system configuration. There's just one sudo command involved (or none if you open the term from desktop menu), and after that you don't have to think about sudo. Just make sure you remember this is a root session so you don't accidentally misuse your power. I have root's PS1 in bright red to keep me aware.
EDIT: the work around, of course, is to change the permissions from the terminal
I would call this dangerous behavior, unless you change the permissions back after the edit. File permissions outside of /home/tc really should be editable only by root (that includes /opt, in my opinion). When you start breaking down those permissions, you are destroying one of the primary aspects of your system's security.
Other incentives for "sudo" include trying to remove a folder without it, and having to go through a questionaire regarding every file inside it. "Sudo" effectively dumps the whole thing instantly....and I'm hooked!
You can also do "rm -rf folder". Using sudo with the "rm" command can easily become hazardous....just a simple accidental keypress at the wrong second can destroy ocean liners and devastate planets....or at least delete some important stuff your system needs to live.
-
I don't know how this would work with vi, but when I do massive edits then can't save them, I save them to /home/tc then as root mv or cp to where they need to be.
I keep using beaver because I know it. Sometime I really need to learn vi. (Or maybe it's just because it's fun sudoing beavers then killing them afterwards ::) ?)
I saw this "Only use you Super Powers when absolutely necessary". But I get what your saying about the number of times a person types sudo. I usually have a terminal and a root terminal open at the same time.
-
You can also do "rm -rf folder". Using sudo with the "rm" command can easily become hazardous....just a simple accidental keypress at the wrong second can destroy ocean liners and devastate planets....or at least delete some important stuff your system needs to live.
I tried "rm =rf" on a folder I created in /home/tc with "sudo mkdir" and got "permission denied".
Edit: It works only if empty, but not if there's a file in it. To make the file, of course, you need to use
"sudo".
-
you shouldn't need to use sudo in /home/tc to create a directory or write a file in it. The executable bit on chmod is different then making a file executable, it makes the directory writable. drwx------ or 700 would allow the owner to write inside the directory or drwxrwxrwx 777 would make it world writable (but also world deletable so I like drwxrwxr-x). So writable is just the directory proper and executable is the contents. Then each file inside the directory has it's own ownership and permissions.
(or at least thats how I understand it works. Still learning.)
Edit: i just created another tce directory with the boot option and it is owned by tc:staff and drwxr-xr-x. I created an optional dir inside it and copied a bunch of extensions there from another tce dir without becoming root.
-
The problem is one of permissions, in which case w! doesn't work for either vim or vi. (ie.,root:root)
I think what he meant by ":w /path/to/filename" was to use a different, writable path. Then, as root, move the new file over the old & change its ownership back to root. It's still an inconvenience, but at least you keep your edits.
Heh, guess I forgot the explanation - thanks.
Simple rule: For anything outside of /home/tc, be root.
Another standard place that's writeable besides ~ is /tmp
You can also do "rm -rf folder". Using sudo with the "rm" command can easily become hazardous....just a simple accidental keypress at the wrong second can destroy ocean liners and devastate planets....or at least delete some important stuff your system needs to live.
I tried "rm =rf" on a folder I created in /home/tc with "sudo mkdir" and got "permission denied".
Edit: It works only if empty, but not if there's a file in it. To make the file, of course, you need to use
"sudo".
I think he meant that always using sudo with rm -rf can be dangerous.
The executable bit on chmod is different then making a file executable, it makes the directory writable. drwx------ or 700 would allow the owner to write inside the directory or drwxrwxrwx 777 would make it world writable (but also world deletable so I like drwxrwxr-x). So writable is just the directory proper and executable is the contents. Then each file inside the directory has it's own ownership and permissions.
+x on directories means pass-through; +r means listing
-
You need to have x on a directory in order to write to (or delete from) it because you need to be able to enter the directory in order to add or delete a file contained within. If your directory is rw-, you can't read the contents of it (the r applies only to the directory file itself, as far as I know), but you can still delete the directory itself if it is empty.
If it's r-x, you can delete it if it's empty (not sure why that works...guessing you at least need to own the directory), and you can also read its contents, but you can't add or delete anything inside. So basically the difference between 500 (dr-x------) and 600 (drw-------) when applied to a directory is that 600 is useless and 500 allows the owner read-only access to its contents. Writing requires both w and x. A typical directory is 755 to allow the owner full access and everyone else read-only access.
I tried "rm =rf" on a folder I created in /home/tc with "sudo mkdir" and got "permission denied".
That's the expected behavior. Anything created with sudo will be owned by root, and therefore you can't delete it as tc. The files in /home/tc are not intended for root. If you do create a file as root within /home/tc and expect to have full control of the file as user tc, you should do 'chown tc' on the file (or 'chown -R tc' for a directory). EDIT: that should preferably be "sudo chown tc.staff" or "sudo chown 1001.50"
-
paraphrasing something I [was] (edit: saw [dyslexia]) on the DSL jokes, "Linux is a simple operating system, but it takes a genius to understand its simplicity". Thanks Mikshaw and TheHatsRule, I put things in terms that I understand which are usually not the write word. And, besides almost a decade writing stuff for web servers, I downloaded my first copy of Linux Dec 2007. I still have much to learn. What I'm catching is that the biggest security feature of Linux is ownership and permissions. A malicious program (or inept or malicious user) can't effect much more then it's self.
P.S. I reformatted the last Windows drive on the last computer that was still multi booting Windows day before yesterday :) :) :). Guess if something isn't used for four months it can go bye bye.
-
What I'm catching is that the biggest security feature of Linux is ownership and permissions.
If your talking about the basic home user, I'd agree (that's not saying it's fact, just my opinion). If you're talking about vital systems like those run by governments, businesses, etc., I think there are other parts of security that are just as important, such as firewalls and keeping software patched with the latest security fixes. In those systems, though, I would say the use of sudo is a bad idea anyway....in that case root power should be given only to trusted administrators.
-
I found a fast way check for files that are able to be written to by anyone (i.e., without 'sudo'), using the 'find' command. So for files in hda3:
find /mnt/hda3 -perm -222
For more (or less) security, I could then use chmod. .
-
It pays to understand permissions. For example, I tried saving a file opened with OO, and didn't have permission, so I changed the /folder to 666 (read write). Guess what happened when I tried to CD to the folder? :D
Edit; to really freak out, try to ls to the files.....it looks like they've all been deleted.
-
I think it really helps to use a file manager which has the ability to display the file permissions at all times. A quick glance will let you know what needs to be done if you have a permissions-related problem. Personally, mc with mode:3 (or 4,5,6,or 7) as part of the file listing mode is great.
-
I think it really helps to use a file manager which has the ability to display the file permissions at all times. A quick glance will let you know what needs to be done if you have a permissions-related problem. Personally, mc with mode:3 (or 4,5,6,or 7) as part of the file listing mode is great
For the uninitiated, one is still faced with the problem of what to do with them. For example, I quickly tried out "find . | cpio -o -H newc | gzip -9 > tinycore.gz " from files unpacked in /tmp, only to receive errors about not having permission to read /usr/bin/sudo and vsudo files....which are ---s--x--x 1 root root. I didn't spend much time looking at it, but didn't notice any mention of this issue where the instructions were listed. Not knowing what execute means for a dir vs a file can become a crisis fairly quickly...
-
There are several files in the base system which are rightly not readable by anyone but root, so when creating a new tinycore, it should be done only as root.
-
There are several files in the base system which are rightly not readable by anyone but root, so when creating a new tinycore, it should be done only as root.
Last night, even in root I got read permission errors for /usr/bin/sudo and vsudo with "find . | cpio -o -H newc | gzip -9 > tinycore.gz" . Tonight, it worked perfectly. Either there's an astrological aspect required (i.e., the planets have to be aligned correctly to get permission) or it just needed your blessing. If it's the latter, I hope you'll be available for the next remaster......
-
Considering file permissions don't limit what root can do I have to guess that the issue is something else. Are you sure it's a "read permission" error, and not a "read" error? If it's the latter, it might be a corrupted file.
-
Considering file permissions don't limit what root can do I have to guess that the issue is something else. Are you sure it's a "read permission" error, and not a "read" error? If it's the latter, it might be a corrupted file.
I reproduced the error. If I use "sudo find . | cpio -o -H newc | gzip -9 > tinycore.gz" I get:
cpio: ./usr/sbin/visudo: Cannot open: Permission denied
cpio: ./usr/bin/sudo: Cannot open: Permission denied
If I go into root with sudo su first and run the command, it works fine. I thought they were the same thing, but guess not.
-
I reproduced the error. If I use "sudo find . | cpio -o -H newc | gzip -9 > tinycore.gz" I get:
cpio: ./usr/sbin/visudo: Cannot open: Permission denied
cpio: ./usr/bin/sudo: Cannot open: Permission denied
If I go into root with sudo su first and run the command, it works fine. I thought they were the same thing, but guess not.
i've experienced issues i would call similar, but a bit of experimenting helped my understanding. (that's assuming i'm right. if i'm not, it didn't help my understanding.)
for example, one might think:
sudo mkdir /tmp/sudotmp && cp /mnt/sda1/* /tmp/sudotmp would copy all files from /mnt/sda1 to /tmp/sudotmp, even if they can only be read by a superuser. actually, the cp command is not sudo'd.
i suspect (you'll have to figure this out) that cpio and gzip as you use them do not have root access. perhaps using sudo before cpio and gzip will help. it may at least explain your message.
-
i suspect (you'll have to figure this out) that cpio and gzip as you use them do not have root access. perhaps using sudo before cpio and gzip will help. it may at least explain your message.
ah---that was it. It needed a separate 'sudo' for each command in the pipe. Thanks (think I'll just go into root, however...... ;) )
-
If I go into root with sudo su first and run the command, it works fine. I thought they were the same thing, but guess not.
It's not the same...using "sudo <command>" is essentially running a command as a regular user, with the regular user's environment, only with a temporary magic wand for that particular command. If you "sudo su" you are becoming root...the same as if you logged in as root...so everything you do after that point is done as root.
What I was never sure of, and never tested, was if sudo passes root through pipes. It looks like it doesn't, according to what you have experienced, though I'm just guessing.
-
afaik the pipe would have the same permissions as the shell it is in, since that is what handles them. For example, you could do something like
sudo sh -c "command | anothercommand"
-
afaik the pipe would have the same permissions as the shell it is in, since that is what handles them. For example, you could do something like sudo sh -c "command | anothercommand"
cpio needs its own 'sudo'. I just tried "sudo zcat ./tinycore.gz | cpio -H newc -i -d --no-absolute-filenames" and got a bunch of permission errors. I ran it again with " sudo zcat ./tinycore.gz | sudo cpio -H newc -i -d --no-absolute-filenames" and it unpacked.
-
My understanding is that sudo will only work on the first of a string of commands in a pipe, eg:
$ sudo command1 | command2 | command3
..so therefore you would need to add sudo to each command in the string that required it.
-
Note the difference of the extra shell.