Hi!
I was wondering if you would consider reducing the number of default
overwrites for shred from 25 to something more like 5?
We'd like to get shred called from more standard packages (starting with
logrotate). For various reasons, plenty of systems seem to have large
enough log files (10s of
FAIL: no-give-up
Thanks for reporting that.
That test is failing because the setuidgid command
is supposed to fail to remove d, but it actually does
remove the directory.
Please change that test so it uses these two setuidgid commands
instead of the one it currently has:
setuidgid
[EMAIL PROTECTED] wrote:
FAIL: no-give-up
Please change that test so it uses these two setuidgid commands
instead of the one it currently has:
setuidgid $NON_ROOT_USERNAME env PATH=$PATH id -a
setuidgid $NON_ROOT_USERNAME env PATH=$PATH truss -o /tmp/rm-log rm -rf d
fail=1
Then, the
From [EMAIL PROTECTED] Thu May 3 12:23:56 2007
...
Thanks, but the important part was the output of id -a.
What does that show?
oops - forgot:
uid=60001(nobody) gid=60001(nobody) groups=60001(nobody)
(each time the same)
Arto
___
[EMAIL PROTECTED] wrote:
Please change that test so it uses these two setuidgid commands
instead of the one it currently has:
setuidgid $NON_ROOT_USERNAME env PATH=$PATH id -a
setuidgid $NON_ROOT_USERNAME env PATH=$PATH truss -o /tmp/rm-log rm -rf d
fail=1
oops - forgot:
uid=60001(nobody)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Blohm, Guntram (I/FP-831, extern) on 5/3/2007 1:56 AM:
gandalf$ tr -c '\012[a-z][A-Z][0-9].' '[_*256]'
tr: tr.c:1819: main: Assertion `get_next (s2, ((void *)0)) == -1 ||
truncate_set1' failed.
Aborted
gandalf$ tr --version
tr
Blohm, Guntram (I/FP-831, extern) [EMAIL PROTECTED] wrote:
gandalf$ tr -c '\012[a-z][A-Z][0-9].' '[_*256]'
tr: tr.c:1819: main: Assertion `get_next (s2, ((void *)0)) == -1 ||
truncate_set1' failed.
Aborted
Thank you for reporting that!
The fix appears to be simply to remove that assertion,
From [EMAIL PROTECTED] Thu May 3 12:40:21 2007
...
oops - forgot:
uid=60001(nobody) gid=60001(nobody) groups=60001(nobody)
Ok. Have you done anything with ACLs?
Maybe there is an ACL in effect that renders your files removable by anyone.
Please add these to the above:
ls -lr d
[EMAIL PROTECTED] wrote:
Why is this so? The script called 'umask 000' because otherwise almost
...
We're getting closer :-)
Your use of 'umask 000' could be part of the problem,
but that doesn't explain why rm's final rmdir(d) succeeded.
The permissions of . (the directory containing d) were
The permissions of . (the directory containing d) were set
to be rwx-- (aka u=rwx), so that rmdir by non-owner should
have failed, regardless of the umask.
I thought chmod u=rwx . only sets user permissions without changing
group or other permissions? Probably it should be chmod 755 . or
ls -ld .
after the line that does chmod u=rwx . in tests/rm/no-give-up,
the output may help.
result:
drwxrwxrwx 3 root other 512 May 3 19:12 .
FAIL: no-give-up
because chmod u=rwx . only changes 'u', not 'go' permissions.
substituting chmod 755 . yields:
drwxr-xr-x 3
[EMAIL PROTECTED] scripsit:
The permissions of . (the directory containing d) were set
to be rwx-- (aka u=rwx), so that rmdir by non-owner should
have failed, regardless of the umask.
I thought chmod u=rwx . only sets user permissions without changing
group or other permissions?
[EMAIL PROTECTED] wrote:
The permissions of . (the directory containing d) were set
to be rwx-- (aka u=rwx), so that rmdir by non-owner should
have failed, regardless of the umask.
I thought chmod u=rwx . only sets user permissions without changing
group or other permissions? Probably it
Jim Meyering [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
The permissions of . (the directory containing d) were set
to be rwx-- (aka u=rwx), so that rmdir by non-owner should
have failed, regardless of the umask.
I thought chmod u=rwx . only sets user permissions without changing
Just noticed before that umask now also influences
coreutils-6.9/test/rm/fail-2eperm
No idea why this didn't show up before - but it didn't (checked the logs from
before,
fail-2eperm passed before, even with umask 000 - does this depend on whether or
not
no-give-up failed beforehand???).
date (coreutils) 5.2.1
Geschrieben von David MacKenzie.
Copyright (C) 2004 Free Software Foundation, Inc.
Dies ist freie Software; die Kopierbedingungen stehen in den Quelltexten. Es
gibt keine Garantie; auch nicht für VERKAUFBARKEIT oder FÜR SPEZIELLE
ZWECKE.
For example, if I type:
date
I
Hello,
This email just to signal that the /usr/bin/stat command in version
5.2.1 of coreutils do have a return code equal to 0 even if the file
argument given do not exist. Is that normal ?
[EMAIL PROTECTED] wrote:
This email just to signal that the /usr/bin/stat command in version
5.2.1 of coreutils do have a return code equal to 0 even if the file
argument given do not exist. Is that normal ?
Thanks for the report.
That's been fixed for some time.
You really should upgrade.
Johannes Schweifer [EMAIL PROTECTED] wrote:
...
My locale settings are german...
All right, if I want to format this with the -d option:
date -d Do Mai 3 16:10:57 CEST 2007 +%H:%M:%S %d-%m-%Y
It is not recognized as a valid date unless I remove the day Do and
fix the month, basically change
Paul Eggert [EMAIL PROTECTED] wrote:
Evan Hunt [EMAIL PROTECTED] writes:
Here's a one-line patch to split.c (plus a few more lines of doc changes
in that file and coreutils.texi) to allow it to emit output files sized in
gigabytes, terabytes, etc.
Sounds reasonable to me, but let's do that
On Wed, 2 May 2007, Peter Eckersley wrote:
I was wondering if you would consider reducing the number of default
overwrites for shred from 25 to something more like 5?
The first question which comes to mind is why 25?
From the first version which I can find:
Philip Rowlands scripsit:
It's tricky to view security/performance tradeoffs to be anything but
ratchet-like, only ever towards security.
Hmm. You know, this ward lock you have on your front door here is
very insecure. It's easy to cut a skeleton key that will open it.
Oh, no problem! We
On Thu, 2007-05-03 at 19:56 +0100, Philip Rowlands wrote:
On Wed, 2 May 2007, Peter Eckersley wrote:
It's tricky to view security/performance tradeoffs to be anything but
ratchet-like, only ever towards security. Perhaps it's even preferable
to make --iterations be a mandatory argument,
On 5/3/07, Peter Eckersley [EMAIL PROTECTED] wrote:
We're certainly working on making sure that userspace chattr()s the
attribute. Apparently, for many journalling filesystems (ext3 and maybe
Reiser, IIRC), shred should still work pretty well as-is -- I guess
that's because the filesystem
I don't think that any of the attacks Wietse discussed are related to
actually reading things out from underneath multiple disk-write cycles
(though he does cite Peter Gutmann's 1996 paper on microscopic attacks,
but the paper applied to older hard disks).
Everything else is about keeping track
Peter Eckersley [EMAIL PROTECTED] writes:
I was wondering if you would consider reducing the number of default
overwrites for shred from 25 to something more like 5?
As near as I can make out, for modern disks the default should be 1.
That's easy to change. Any objections?
There's also the
Output of uname -a:
Darwin ppc7447.local 8.9.0 Darwin Kernel Version 8.9.0: Thu Feb 22
20:54:07 PST 2007; root:xnu-792.17.14~1/RELEASE_PPC Power Macintosh
powerpc PowerMac10,1 Darwin
output of hostid --version:
hostid (GNU coreutils) 6.9
Built using gcc 4.0.4 [custom compiled] plus the
This is in relation to an old bug listed here.
http://lists.gnu.org/archive/html/bug-coreutils/2005-10/msg00181.html
I happened to be using an old copy of coreutils and noticed many of the
old options status -c, atime -u, access -u, use -u did not work. The patch
in the thread got rid of them
C. Speare scripsit:
A possible (but weak) workaround is to test for the case where id is 0.
It's fine to detect that case, but the whole idea of hostid is to
return the same value each time it's called on the same host,
so returning a random value is unhelpful.
--
Work hard,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Michael A Stevens on 5/3/2007 8:46 PM:
This is in relation to an old bug listed here.
http://lists.gnu.org/archive/html/bug-coreutils/2005-10/msg00181.html
First, thanks for the efforts, even if Jim decides not to use them.
I
On Thu, 2007-05-03 at 19:05 -0700, Paul Eggert wrote:
Peter Eckersley [EMAIL PROTECTED] writes:
I was wondering if you would consider reducing the number of default
overwrites for shred from 25 to something more like 5?
As near as I can make out, for modern disks the default should be 1.
On Thu, 3 May 2007, Eric Blake wrote:
Of the files in your patch, only the changes to ls.c are needed; the files
in man/ and po/ are generated files (either by help2man or by the
translation project), so patching them directly is not required and only
makes it harder to see the real patch.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Michael A Stevens on 5/3/2007 9:44 PM:
Of the files in your patch, only the changes to ls.c are needed; the
files
in man/ and po/ are generated files (either by help2man or by the
translation project), so patching them directly is not
33 matches
Mail list logo
