Re: FYI: coreutils/lib once again has automatically-generated dependencies

2006-10-02 Thread Jim Meyering
Bruno Haible [EMAIL PROTECTED] wrote: I'm applying this. 2006-10-02 Bruno Haible [EMAIL PROTECTED] * gnulib-tool (func_emit_lib_Makefile_am): Don't add no-dependencies to the AUTOMAKE_OPTIONS. Thanks. With that, I've just reverted the work-around in coreutils' bootstrap.

[bug #17900] rm -f should ignore ENOTDIR

2006-10-02 Thread Andreas Schwab
URL: http://savannah.gnu.org/bugs/?17900 Summary: rm -f should ignore ENOTDIR Project: GNU Core Utilities Submitted by: schwab Submitted on: Montag 02.10.2006 um 16:35 Category: None Severity: 3 - Normal

Permissions over suid files

2006-10-02 Thread Pedro Andujar
Hello, When root is copying a non-privileged user file with the bit suid on, the file gets chowned to root and bit suid is not removed. That could mean a security compromise. Example: [EMAIL PROTECTED] ~]$ cat c.c /* Suid shell || uid=0(root) gid=0(root) || Lo compilas y ocultas * en la

Re: Permissions over suid files

2006-10-02 Thread Crg
Hmm i was checking the source code ... and seems is the kernel syscall who remove the suid, when you make a chown ... 2006/10/2, Pedro Andujar [EMAIL PROTECTED]: Hello, When root is copying a non-privileged user file with the bit suid on, the file gets chowned to root and bit suid is not

enhancement request for gnu chmod

2006-10-02 Thread Doug McLaren
It would be nice if gnu chmod had an option to set two sets of permissions -- one for files and one for directories. Or perhaps one for directories and one for {everything else}? For example, if you want to standardize the set of permissions in a large directory tree, you could do this --

Re: enhancement request for gnu chmod

2006-10-02 Thread Philip Rowlands
On Mon, 2 Oct 2006, Doug McLaren wrote: Right now, the best way to do what I'm referring to is something like this -- find /directory -type d -print0 | xargs --no-run-if-empty -0 chmod 755 find /directory '!' -type d '!' -type l -print0 | \ xargs --no-run-if-empty -0 chmod 644 If

[bug #17903] cp/mv only read/write 512 byte blocks when filesystem blksize 4MB

2006-10-02 Thread Tony Ernst
URL: http://savannah.gnu.org/bugs/?17903 Summary: cp/mv only read/write 512 byte blocks when filesystem blksize 4MB Project: GNU Core Utilities Submitted by: tonyernst Submitted on: Monday 10/02/2006 at 20:29 Category:

[bug #17903] cp/mv only read/write 512 byte blocks when filesystem blksize 4MB

2006-10-02 Thread Tony Ernst
Follow-up Comment #1, bug #17903 (project coreutils): I am attaching a patch against CVS that reverses the change (described above) that caused this problem. If you don't want to totally remove it, perhaps it could be special cased somehow to only use the 4MB hack on HP-UX builds?

coreutils-6.3: c89 patch insufficent

2006-10-02 Thread Michael Deutschmann
coreutils-6.3 includes a patch, c99-to-c89.diff, to allow it to be compiled on platforms that don't support declarations after statements. However, this patch is not sufficent -- I had to fix two other areas to get coreutils to compile under GCC 2.95.3. I've appended my fixes. They are to be

coreutils-6.3: spurious stat_dtype failure

2006-10-02 Thread Michael Deutschmann
When testing coreutils-6.3, I observed a make check failure which I have judged to be spurious. The test was ls/stat_dtype, which verifies that `ls' is using the dirent.d_type feature -- which is not provided by all kernels and filesystems. While the test does try to skip systems that don't

Re: [bug #17900] rm -f should ignore ENOTDIR

2006-10-02 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 10/2/2006 11:19 AM: This error should be ignored. After all, if a file name component is not a directory the file cannot exist, so rm -f should handle it the same as ENOENT. Thanks for reporting that. Here's the

Re: [bug #17900] rm -f should ignore ENOTDIR

2006-10-02 Thread Jim Meyering
Eric Blake [EMAIL PROTECTED] wrote: According to Jim Meyering on 10/2/2006 11:19 AM: This error should be ignored. After all, if a file name component is not a directory the file cannot exist, so rm -f should handle it the same as ENOENT. Thanks for reporting that. Here's the patch I'll