The command tac does not obtain to read memory archives that are located in
/proc.
Example:
#tac /proc/cpuinfo
Att,
Raul Da Silva // Sp4wn_R0ot
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
My frend, this command chmod -R -o+rwx directry is not ok. Only using
chmod -R 775 directory that i had sucess.
Thanks,
Sorry by my inglesh
Rafael.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
Sp4wn Root [EMAIL PROTECTED] wrote:
The command tac does not obtain to read memory archives that are located in
/proc.
Example:
#tac /proc/cpuinfo
Thank you for the report.
That's fixed in the latest test release.
ftp://alpha.gnu.org/gnu/coreutils/
Paul Eggert wrote:
There could be some kind of -f, --follow option so that mkdir will
create the directory pointed to.
There is a potential security problem there, if the symbolic link
is in a directory writable by an attacker.
I don't agree that this is a security problem, since mkdir is doing
POSIX requires this, but it is arguably a misfeature, due to the
security issues mentioned.
I still don't understand how this is a security issue any more than the
whole concept of symbolic links is a security issue.
Yes, that's the problem basically. If you're about to say touch /tmp/foo
an
Rafael Correa Liberato [EMAIL PROTECTED] writes:
My frend, this command chmod -R -o+rwx directry is not ok.
-o+rwx isn't what you wanted. It means If other people have
permissions to the file then remove them; but after that, grant all
permissions; except do not affect any permissions that are
Eric J Haywiser [EMAIL PROTECTED] writes:
I would expect the 2nd command to behave like this:
[EMAIL PROTECTED] ~/coreutils-5.3.0/src/ls -lF
total 1
-rwxr-xr-x exe*
lrwxrwxrwx n@ - nonexistant
lrwxrwxrwx x@ - exe
I can see your point: that would be logical, and it seems to be
