Re: mknod
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Costa on 4/14/2005 8:07 AM: Hi Everybody, I have a problem on cygwin: You should ask this question on the cygwin mailing list, [EMAIL PROTECTED] mknod pipe p POSIX states that named pipes (aka fifos) are only portable if used in one direction (ie. you can't open them read-write and expect portable results). Beyond that, named pipes are a relatively new addition to cygwin, and there are still bugs being ironed out. For example, $ mkfifo f # shorthand for mknod f p $ ls -iF f 1125899907358221 f| $ mv f f1 $ ls -iF f1 1125899907358221 f1 preserves the inode, but changes the file type from pipe to a regular file (read-only at that). - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCXwZS84KuGfSFAYARAl30AKCir40E0f1Y5SySvAmXN6GNk62dMgCg1kN7 b4tS9djYzJ84Z0z6j+oZWvM= =2Kee -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug#304556: file permissions race in mkdir, mknod, mkfifo (CAN-2005-1039)
My kneejerk reaction is that it's not worth making this change. The attack in question will work against almost any program that is operated in an insecure directory, including the chmod program itself. It'd be a real pain to work around this problem in all applications, one at a time, and it's not at all clear to me that it's even doable in general. I suggest simply warning users that if you let bad guys modify your directories, you're asking for trouble. Which is certainly true in any event. That being said, it would be an easy security improvement if mkdir -m would use lchmod rather than chmod, on platforms where lchmod is available. There may be several other programs where this would be advisable as well, and similarly for lchown versus chown. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: I need a bi-directional FIFO
On Mon, Apr 11, 2005 at 03:07:13PM -0500, Alan Grimes wrote: before I disconnect my modem and install a serial loop-back cable, do I have any software alternatives to this problem? Sounds like you want a PF_LOCAL socket. See 'man unix' for information about them. (This isn't really a coreutils question though.) Tim. */ pgpMlYXcDilZZ.pgp Description: PGP signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cygwin failing tests/mv/mv-special-1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paul Eggert on 4/14/2005 2:37 PM:
Thanks for that bug report. I installed this patch: does it fix both
your problems?
Almost - there are some further cleanups that can be made. First, we
might as well dereference symlinks (one of the CANDIDATE_TMP_DIRS could be
a cross-device symlink instead of a mount point). Second, this is
coreutils, so we have a reliable test(1) - the comment about `test -e' not
being portable is irrelavant. Third, mv-special-1 is not being careful
that the named pipe is still a named pipe on the destination.
2005-04-15 Eric Blake [EMAIL PROTECTED] (tiny change)
* tests/mv/mv-special-1: Use our own test(1) to check that
hierarchy was correctly moved.
* tests/mv/setup (dot_mount_point): Dereference symlinks when
learning device number.
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCX7lV84KuGfSFAYARAgJoAJ9PRrTye40nmA1oVBMLutYkrYfh7QCeJ3tb
OBGpeaxOxrfwwwOqcFeEodc=
=j0Mw
-END PGP SIGNATURE-
Index: tests/mv/mv-special-1
===
RCS file: /cvsroot/coreutils/coreutils/tests/mv/mv-special-1,v
retrieving revision 1.24
diff -u -p -r1.24 mv-special-1
--- tests/mv/mv-special-1 14 Apr 2005 20:35:14 - 1.24
+++ tests/mv/mv-special-1 15 Apr 2005 12:51:52 -
@@ -43,11 +43,11 @@ fi
fail=0
mv --verbose $null $dir $other_partition_tmpdir out || fail=1
# Make sure the files are gone.
-test -f $null fail=1
+# shell builtin test -e is not portable, so use our own
+${BUILD_SRC_DIR?}/test -e $null fail=1
test -d $dir fail=1
# Make sure they were moved.
-# Since `test -e' is not portable, use `ls'.
-ls $other_partition_tmpdir/$null /dev/null || fail=1
+$BUILD_SRC_DIR/test -p $other_partition_tmpdir/$null || fail=1
test -d $other_partition_tmpdir/$dir/a/b/c || fail=1
# POSIX says rename (A, B) can succeed if A and B are on different file
systems,
Index: tests/mv/setup
===
RCS file: /cvsroot/coreutils/coreutils/tests/mv/setup,v
retrieving revision 1.13
diff -u -p -r1.13 setup
--- tests/mv/setup 14 Apr 2005 20:35:34 - 1.13
+++ tests/mv/setup 15 Apr 2005 12:51:52 -
@@ -9,13 +9,13 @@ test ${CANDIDATE_TMP_DIRS+set} = set \
other_partition_tmpdir=
-dot_mount_point=`stat -c %d .`
+dot_mount_point=`stat -Lc %d .`
for d in $CANDIDATE_TMP_DIRS; do
# Skip nonexistent directories.
test -d $d || continue
- d_mount_point=`stat -c %d $d`
+ d_mount_point=`stat -Lc %d $d`
# Same partition? Skip it.
test x$d_mount_point = x$dot_mount_point continue
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Bug in function date
Dear Sir, I'm using red hat enterprise and I'm having problems with function date. When I call it with the sintax bellow, it returns me the following line, as expected: comand: date -d 2005-02-18 00:00:00 24 hour +%y%m%d%H returns: 05021900 comand: date -d 2005-02-20 00:00:00 24 hour +%y%m%d%H returns: 05022100 But when I configure february, 19th of 2005, it returns the wrong date: comand: date -d 2005-02-19 00:00:00 24 hour +%y%m%d%H returns: 05021923 This bug only happens with this specific day. Hope you can help me. Best Regards Leo :: Leonardo Marques da Cruz PROOCEANO Praça Floriano, 55 - s. 707 Cinelândia, Rio de Janeiro - RJ Tel/Fax: (21) 2532.5666 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.9.11 - Release Date: 14/4/2005 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug#304556: file permissions race in mkdir, mknod, mkfifo (CAN-2005-1039)
Paul Eggert [EMAIL PROTECTED] wrote: My kneejerk reaction is that it's not worth making this change. The attack in question will work against almost any program that is operated in an insecure directory, including the chmod program itself. It'd be a real pain to work around this problem in all applications, one at a time, and it's not at all clear to me that it's even doable in general. I suggest simply warning users that if you let bad guys modify your directories, you're asking for trouble. Which is certainly true in any event. That being said, it would be an easy security improvement if mkdir -m would use lchmod rather than chmod, on platforms where lchmod is available. There may be several other programs where this would be advisable as well, and similarly for lchown versus chown. I would be more interested in that approach if I knew that lchmod support were coming to Linux sometime soon. I see that NetBSD, OpenBSD, HPUX (but not Solaris) provide it. This reminds me of Solaris' very nice openat, fdopendir, fstatat functions[1]. They too provide useful functionality that can't be emulated cleanly, yet Linux doesn't provide the necessary syscalls. I suppose a weak replacement function is the `right' way to go -- then, as for openat, redirect complaints to the Linux kernel folks. Jim -- [1] I'm not interested in attribute-related semantics of openat, but rather in the fd-relative-open--related semantics. openat et.al. are very useful in any code that would otherwise have to change to a new directory and then later return to the initial working directory. No code that tries to do that with chdir (or even with open/fchdir) can be truly robust, but it's easy with openat and company. The problem is that sometimes it is impossible to return, even with open/fchdir. With openat, you define away the problem by making it unnecessary to change the current working directory. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
