sudo'd out

[jpeters]

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...

[mikshaw]

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.

[jpeters]

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......

[mikshaw]

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.

[jpeters]

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:

Code: [Select]

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. 

[tobiaus]

I reproduced the error. If I use "sudo find . | cpio -o -H newc | gzip -9 > tinycore.gz"  I get:

Code: [Select]

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.

[jpeters]

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...... )

[mikshaw]

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.

[^thehatsrule^]

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

Code: [Select]

sudo sh -c "command | anothercommand"

[jpeters]

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

Code: [Select]

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.

[Juanito]

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.

[^thehatsrule^]

Note the difference of the extra shell.