command tac ??
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 http://lists.gnu.org/mailman/listinfo/bug-coreutils
Bus
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 http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: command tac ??
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/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
RE: mkdir when target exists and is a broken symlink
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 exactly what you asked it to. But anyway, Is this a sensible thing to put in mkdir or is there some existing Unix idiom that does what I want? Not in POSIX/Unix, but in coreutils 5.3.0 and later: either mkdir -p $(readlink -f file) or mkdir -p $(readlink -m file), depending on the exact semantics that you want. Yes, that would do the trick. I note that 'touch foo' when foo is a broken symlink will create the link destination if possible (though without making any directories, obviously). 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. I'll wait for a newer coreutils release, and instead of using 'mkdir -p' as the standard way of trying hard to make a directory, use instead 'mkdir -p `readlink -f`'. -- Ed Avis [EMAIL PROTECTED] ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mkdir when target exists and is a broken symlink
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 attacker can do ln -s /victim/.newsrc /tmp/foo. I'll wait for a newer coreutils release, and instead of using 'mkdir -p' as the standard way of trying hard to make a directory, use instead 'mkdir -p `readlink -f`'. Given what you said that you wanted, you might prefer -m instead. And you might want to quote things (to protect against link expansions with shell metacharacters), and protect against file names or link expansions with leading -. Something like this, perhaps: mkdir -p -- $(readlink -m -- $file) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bus
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 masked out by the umask. If this is all gobbledygook to you don't worry; the point is that the option doesn't mean what you thought it meant. Only using chmod -R 775 directory that i had sucess. chmod -R ug=rwx,o=rx directory does that. But did you really want to make every file executable? If not, chmod -R ug=rwX,o=rX directory might have been better: this grants execute permissions only to files that are directories or that already have execute permission for some user. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls -lF dereferences symbolic links - ?bug or feature?
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 consistent with what POSIX requires. POSIX http://www.opengroup.org/onlinepubs/009695399/utilities/ls.html says that -F is not supposed to follow symbolic links, and if that is the case then coreutils is incorrect to output x - exe* in the last line (where the * is derived by following the symlink). However, POSIX is not entirely clear in this area, as its formats for ls -l outputs don't specify where the -F decorations are to be placed. Also, this is longstanding behavior, both in coreutils and in traditional UNIX. For example, on Solaris 9: $ touch exe; chmod 755 exe $ ln -sf nonexistant n $ ln -sf exe x $ /usr/xpg4/bin/ls -lF total 4 -rwxr-xr-x 1 eggert eggert 0 May 20 14:27 exe* lrwxrwxrwx 1 eggert eggert11 May 20 14:28 n - nonexistant lrwxrwxrwx 1 eggert eggert 3 May 20 14:28 x - exe* Also, there is a usability argument for the traditional behavior in common use. First, the @ - is redundant; anything with an arrow must be a symbolic link, so there's little point to the @. Second, it's useful for people to see the type of file the symbolic link is pointing to. I suspect that this is a bug in POSIX, since it is vague and in at least one spot is specifying behavior that is contrary to common practice. Perhaps you can take this up with the POSIX committee by filing an Aardvark? http://www.opengroup.org/austin/defectform.html In the mean time I'm afraid that I'm inclined to let sleeping dogs lie. There is a similar issue with ls -lp. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
