whoops didn't notice the debbugs email
reproduced 7 times now, same results. usually 260-280 seconds.
On Mon, Sep 25, 2023 at 4:43 PM Jeffrey Cliff wrote:
>
> Run the full test suite now at least 6 times, same results. Would you
> like me to run them more?
>
> last couple of tests/rm/ext3-perf
On 9/23/23 18:35, Jeffrey Cliff wrote:
Test suite told me to send this report in so here we are.
environment : custom LFS (GNM)
coreutils: 9.4
gcc: (GCC) 13.2.0
> FAIL: tests/rm/ext3-perf
>
> [...]
>
> ++ date +%s
> + start=1698065263
> + mkdir d
> + cd d
> + xargs
Hello,
[reproduced with rm 8.30 and current git head on ubuntu 20.04 amd64]
Whilst trying to answer
https://unix.stackexchange.com/questions/505317/using-rm-one-file-system-to-only-delete-files-on-the-local-filesystem
I noticed that "rm -rf --preserve-root=all some-dir" was not race-f
On 2020-07-31 21:42, Pádraig Brady wrote:
> Patch looks good thanks.
Thanks.
> An alternative could be to use rmdir itself to test, like:
>
>if ! rmdir x/y 2>/dev/null; then
> returns_ 1 rmdir --ignore-fail-on-non-empty x/y || fail=1
>fi
I thought about that, but as there's a
On 31 Jul 2020, Bernhard Voelker spake thusly:
> On 2020-07-31 16:32, Nick Alcock wrote:
>> I get an ERROR when running rmdir/ignore.sh as root (but not when
>> running as non-root). [...]
>
>> ERROR: tests/rmdir/ignore
>> =
> [...]
&
On 31/07/2020 18:56, Bernhard Voelker wrote:
On 2020-07-31 16:32, Nick Alcock wrote:
I get an ERROR when running rmdir/ignore.sh as root (but not when
running as non-root). [...]
ERROR: tests/rmdir/ignore
=
[...]
+ mkdir -p x/y
+ chmod a-w x
+ returns_ 1 rmdir
On 2020-07-31 16:32, Nick Alcock wrote:
> I get an ERROR when running rmdir/ignore.sh as root (but not when
> running as non-root). [...]
> ERROR: tests/rmdir/ignore
> =
[...]
> + mkdir -p x/y
> + chmod a-w x
> + returns_ 1 rmdir --ignore-fail-on-non
I get an ERROR when running rmdir/ignore.sh as root (but not when
running as non-root). The running system has coreutils 8.31 installed;
The source tree, /usr/src/coreutils/x86_64-loom, is a loopback mount of
an xfs filesystem dedicated only to this build. (The build subdir
shai-build has nothing
retitle 24217 dd: add root partition checks/confirmation
severity 24217 wishlist
tags 24217 wontfix
close 24217
stop
(triaging old bugs)
On 2016-08-13 8:15 a.m., Pádraig Brady wrote:
On 13/08/16 12:34, David Hedlund wrote:
rm / # do not remove root partition
rm -f / will remove root partition
tags 21405 moreinfo
close 21405
stop
(triaging old bugs)
On 03/09/15 10:00 AM, Pádraig Brady wrote:
On 03/09/15 16:02, John Bowling wrote:
This is a repeat of the bug around 2009.
Well need more info.
Which version of df are you using?
Do you have a reference to the original discussion?
On 06/11/17 04:06, Thomas Deutschmann wrote:
> Hi,
>
> here's a better fix (from Sebastian Kühn via
> https://bugs.gentoo.org/353164):
>
> diff --git a/tests/ls/readdir-mountpoint-inode.sh
> b/tests/ls/readdir-mountpoint-inode.sh
> index b4ca9e46e..5270df079 100755
> ---
Hi,
here's a better fix (from Sebastian Kühn via
https://bugs.gentoo.org/353164):
diff --git a/tests/ls/readdir-mountpoint-inode.sh
b/tests/ls/readdir-mountpoint-inode.sh
index b4ca9e46e..5270df079 100755
--- a/tests/ls/readdir-mountpoint-inode.sh
+++ b/tests/ls/readdir-mountpoint-inode.sh
@@
Hi,
test "tests/ls/readdir-mountpoint-inode.sh" is unstable and should
require root privileges because it will fail when it encounters
permissions like
> # df --local --out=target | sed -n '/^\/./p'
> /dev
> /run
> /dev/shm
> /sys/fs/cgroup
> /boot
> /usr/portage
On 13/08/16 12:34, David Hedlund wrote:
> rm / # do not remove root partition
> rm -f / will remove root partition
>
> In my opinion:
>
> dd of=/dev/sda # will destroy sda even if it is a root partition, it
> should not
> dd -f of=/dev/sda # -f flag do not exists for d
rm / # do not remove root partition
rm -f / will remove root partition
In my opinion:
dd of=/dev/sda # will destroy sda even if it is a root partition, it
should not
dd -f of=/dev/sda # -f flag do not exists for dd, it should be added so
it can force a write if the previous step
M +0200, Bernhard Voelker wrote:
> > On 06/15/2016 06:31 PM, Al Mamun wrote:
> > > I was trying to "su - nonrootuser" but it returns incorrect password
> but
> > > the password is ok and I can login from ssh. Everything is good with
> root.
> > > Only th
Hi,
On Thu, Jun 16, 2016 at 07:44:06AM +0200, Bernhard Voelker wrote:
> On 06/15/2016 06:31 PM, Al Mamun wrote:
> > I was trying to "su - nonrootuser" but it returns incorrect password but
> > the password is ok and I can login from ssh. Everything is good with root.
&
tag 23773 notabug
thanks
On 06/15/2016 06:31 PM, Al Mamun wrote:
> Hi,
>
> I was trying to "su - nonrootuser" but it returns incorrect password but
> the password is ok and I can login from ssh. Everything is good with root.
> Only the non-root user is causing the
tag 20111 notabug
close 20111
stop
coreutils nice docs don't mention the root user.
renice is implemented by util-linux so CCing there.
thanks,
Pádraig.
On 15/03/15 18:32, Stéphane Aulery wrote:
> Hello,
>
> I had you followed a bug reported by a Ubuntu user [1] about "nice va
This is a repeat of the bug around 2009.
On 03/09/15 16:02, John Bowling wrote:
> This is a repeat of the bug around 2009.
Well need more info.
Which version of df are you using?
Do you have a reference to the original discussion?
thanks,
Pádraig
Hello,
I had you followed a bug reported by a Ubuntu user [1] about nice value
change:
According to man nice and info coreutils nice, it is
not possible for a non-root user to decrease the niceness
of a process (even if they were the ones that increased the
niceness). However
Hi!
On systems like linux, cp / -a --one-file-system (destination) will
not copy whole root filesystem. It is not cp's fault, but the
behaviour is quite surprising to the users, so maybe it would be worth
warning in man page?
Something like
-x, --one-file-system
stay
severity 14383 wishlist
thanks
Pavel Machek wrote:
On systems like linux, cp / -a --one-file-system (destination) will
not copy whole root filesystem. It is not cp's fault, but the
behaviour is quite surprising to the users, so maybe it would be worth
warning in man page?
Something like
Hi!
But isn't that the entire purpose of -x? To avoid copying files on
other file systems?
I am just not sure about having a description that is don't copy
files on other filesystems and then warning: does not copy files on
other filesystems.
I have never liked the wording of stay on
On 05/10/2013 11:55 AM, Pavel Machek wrote:
Hi!
On systems like linux, cp / -a --one-file-system (destination) will
not copy whole root filesystem. It is not cp's fault, but the
behaviour is quite surprising to the users, so maybe it would be worth
warning in man page?
Something like
Pádraig Brady p...@draigbrady.com writes:
I suppose you could give the advice to ensure that all
mounts in a tree should be unmounted to ensure that
the base file system contents are copied.
The easiest way to uncover all over-mounted files of a filesystem is to
bind-mount it somewhere else.
Andreas Schwab wrote:
Pádraig Brady writes:
I suppose you could give the advice to ensure that all
mounts in a tree should be unmounted to ensure that
the base file system contents are copied.
The easiest way to uncover all over-mounted files of a filesystem is to
bind-mount it
On 11/20/2012 08:31 PM, Michael Felt wrote:
root@x104:[/data/prj/gnu/
coreutils/coreutils-8.20]cd tests
root@x104:[/data/prj/gnu/coreutils/coreutils-8.20/tests]truss -f -o /tmp/tr
m
cd .. make check TESTS=tests/tail-2/F-vs-missing.sh SUBDIRS=.
All make invocations must be from the top level
On 11/15/2012 08:00 AM, Michael Felt wrote:
FAIL: tests/rm/d-2.sh (exit: 1)
===
+ diff -u exp out
--- exp2012-11-14 22:58:24 +0100
+++ out2012-11-14 22:58:23 +0100
@@ -1 +1 @@
-rm: cannot remove 'd': Directory not empty
+rm: cannot remove 'd': File
Pádraig Brady wrote:
On 11/15/2012 08:00 AM, Michael Felt wrote:
FAIL: tests/rm/d-2.sh (exit: 1)
===
+ diff -u exp out
--- exp 2012-11-14 22:58:24 +0100
+++ out 2012-11-14 22:58:23 +0100
@@ -1 +1 @@
-rm: cannot remove 'd': Directory not empty
+rm:
root@x104:[/data/prj/gnu/
coreutils/coreutils-8.20]cd tests
root@x104:[/data/prj/gnu/coreutils/coreutils-8.20/tests]truss -f -o /tmp/tr
m
cd .. make check TESTS=tests/tail-2/F-vs-missing.sh SUBDIRS=.
make[1]: Entering directory `/data/prj/gnu/coreutils/coreutils-8.20'
GENpublic-submodule
- Mail original -
De: Matt Burgess matt...@linuxfromscratch.org
À: 12...@debbugs.gnu.org
Cc: matt...@linuxfromscratch.org
Envoyé: Jeudi 1 Novembre 2012 21:29:33
Objet: bug#12778: Failure when running check-root make target
Hi,
When running 'make NON_ROOT_USERNAME=nobody check
FYI
test-suite.log.gz
Description: GNU Zip compressed data
The compressed nohup.out - for what is it worth, or not - attached.
On Thu, Nov 15, 2012 at 9:00 AM, Michael Felt mamf...@gmail.com wrote:
FYI
nohup.out.gz
Description: GNU Zip compressed data
There are a lot of failures there, though none seem to
be all that serious for real-world use. Probably the best
thing to do is to go through them one by one. The first
failure is in tests/tail-2/F-vs-missing.sh, and the log
says:
+ rm -rf
Andrew Warshall wrote: (Sunday, November 04, 2012 8:21 PM)
make[7]: *** No rule to make target `tests/chown/basic.sh.log',
needed by `test-suite.log'. Stop.
Is anyone else having our problem?
In particular, is it local to GNU make 3.82?
well, not the same, but ...
make check-TESTS
] Error 2
This is on OpenSuSE 12.2 with GNU make 3.82.
I'd be curious to know what it's supposed to be doing. For example,
should make check-root be running any gnulib-tests at all? Those
should all get run by make check anyway, no?
Does make NON_ROOT_USERNAME=nobody check-TESTS run as root
Andrew Warshall wrote (Monday, November 05, 2012 3:30 PM):
This is on OpenSuSE 12.2 with GNU make 3.82.
I'd be curious to know what it's supposed to be doing. For example,
should make check-root be running any gnulib-tests at all? Those
should all get run by make check anyway, no?
not sure
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 5 Nov 2012 15:46:32 +
Voelker, Bernhard bernhard.voel...@siemens-enterprise.com wrote:
Does make NON_ROOT_USERNAME=nobody check-TESTS run as root in the
gnulib-tests/ directory work for you?
Sure it does. ;-)
But with sudo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
When running 'make NON_ROOT_USERNAME=nobody check-root' on
coreutils-8.20, I get:
CCLD test-xvasprintf
CC test-yesno.o
CCLD test-yesno
make[6]: Leaving directory
`/home/burgessm/sources/coreutils-8.20/gnulib-tests'
make
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
When running 'make NON_ROOT_USERNAME=nobody check-root' on
coreutils-8.20, I get:_ROOT_USERNAME=nobody check-
CCLD test-xvasprintf
CC test-yesno.o
CCLD test-yesno
make[6]: Leaving directory
`/home/burgessm
Hi,
When running 'make NON_ROOT_USERNAME=nobody check-root' on
coreutils-8.20, I get:
CCLD test-xvasprintf
CC test-yesno.o
CCLD test-yesno
make[6]: Leaving directory
`/home/burgessm/sources/coreutils-8.20/gnulib-tests'
make check-TESTS
make[6]: Entering directory
`/home/burgessm
Hi,
I found a bug (or say lack of functionality) in chmod. I tried to change
the permission of a file (normal .txt file) owned by root using:
sudo chmod -x file.txt
It returned silent prompt but the file permissions were unchanged. I tried
the same with logging in as root and again hit:
chmod
tags 11009 notabug
On 03/13/2012 01:05 PM, Nikhil Vidhani wrote:
Hi,
I found a bug (or say lack of functionality) in chmod. I tried to change
the permission of a file (normal .txt file) owned by root using:
sudo chmod -x file.txt
It returned silent prompt but the file permissions were
Need to change file ownership permissions from root to my user/group
(john/john). Using the test file Augustine.doc, I issue the command in
terminal:
sudo chown john:john Augustine.doc
No error message returned but checking properties of the file it still
is shown as root.
I then try
* John McMillan (mcmil...@skybest.com) [20100825 19:06]:
to which I receive the following confirmation -
changed ownership of `/media/C:/Documents and Settings/John/My
Documents/Word/John/Augustine.doc' to john:john
Looks like this is a DOS/WIN partition, i.e. vfat or ntfs. These file
systems
On 08/25/2010 11:23 AM, Philipp Thomas wrote:
* John McMillan (mcmil...@skybest.com) [20100825 19:06]:
to which I receive the following confirmation -
changed ownership of `/media/C:/Documents and Settings/John/My
Documents/Word/John/Augustine.doc' to john:john
Looks like this is a DOS/WIN
On 14/04/10 15:37, Pádraig Brady wrote:
On 14/04/10 14:52, Jim Meyering wrote:
tests: avoid spurious failure of root-only ls/capability test
Here's another ls test failure that happens on SELinux enabled systems.
I'll push the following shortly.
From
Hmm... you can tell I haven't been running the root-only tests
on capability-enabled systems. This showed up as a root-only failure:
$ sudo env PATH=$PATH NON_ROOT_USERNAME=$USER make -k check-root
PASS: chown/basic
...
PASS: install/install-C-root
FAIL: ls/capability
On 14/04/10 14:52, Jim Meyering wrote:
tests: avoid spurious failure of root-only ls/capability test
Here's another ls test failure that happens on SELinux enabled systems.
I'll push the following shortly.
From 2d9e9408f74f39f4c2817ea028a7a6ad64fb4b45 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?P
:
http://www.gnu.org/software/coreutils/faq/#Why-can-only-root-chown-files_003f
Since this bug report was submitted anonymously there is no way to send you
information other than in this report. If you wish further discussion I
suggest sending a message to the bug-coreutils mailing list
* tests/touch/not-owner: Handle the case when the root file system is
mounted read-only.
Reported by Solar Designer.
---
tests/touch/not-owner |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/tests/touch/not-owner b/tests/touch/not-owner
index 3dd8a80..9cfa026 100755
Dmitry V. Levin wrote:
* tests/touch/not-owner: Handle the case when the root file system is
mounted read-only.
Reported by Solar Designer.
Thanks!
Applied.
Good idea to mount root read-only.
Voelker, Bernhard wrote:
Jim Meyering wrote:
Voelker, Bernhard wrote:
I'm wondering why there are so many tests (in coreutils-8.0( run by
sudo env PATH=$PATH NON_ROOT_USERNAME=$USER make -k check-root
which are skipped with must be run as non-root,
e.g. touch/read-only, mv/perm-1
Jim Meyering wrote:
Voelker, Bernhard wrote:
Jim Meyering wrote:
Voelker, Bernhard wrote:
I'm wondering why there are so many tests (in coreutils-8.0( run by
sudo env PATH=$PATH NON_ROOT_USERNAME=$USER make -k check-root
which are skipped with must be run as non-root
Voelker, Bernhard wrote:
Jim Meyering wrote:
Voelker, Bernhard wrote:
Jim Meyering wrote:
Voelker, Bernhard wrote:
I'm wondering why there are so many tests (in coreutils-8.0( run by
sudo env PATH=$PATH NON_ROOT_USERNAME=$USER make -k check-root
which are skipped
Jim Meyering wrote:
Voelker, Bernhard wrote:
Jim Meyering wrote:
Voelker, Bernhard wrote:
Jim Meyering wrote:
Voelker, Bernhard wrote:
I'm wondering why there are so many tests (in coreutils-8.0( run by
sudo env PATH=$PATH NON_ROOT_USERNAME=$USER make -k check-root
Jim Meyering wrote:
Voelker, Bernhard wrote:
I'm wondering why there are so many tests (in coreutils-8.0( run by
sudo env PATH=$PATH NON_ROOT_USERNAME=$USER make -k check-root
which are skipped with must be run as non-root,
e.g. touch/read-only, mv/perm-1, etc
Voelker, Bernhard wrote:
I'm wondering why there are so many tests (in coreutils-8.0( run by
sudo env PATH=$PATH NON_ROOT_USERNAME=$USER make -k check-root
which are skipped with must be run as non-root,
e.g. touch/read-only, mv/perm-1, etc.
Is that on purpose (to check wether the root
Hi,
I'm wondering why there are so many tests (in coreutils-8.0( run by
sudo env PATH=$PATH NON_ROOT_USERNAME=$USER make -k check-root
which are skipped with must be run as non-root,
e.g. touch/read-only, mv/perm-1, etc.
Is that on purpose (to check wether the root check works
a failure when running tail-2/wait as root
* tests/tail-2/wait: Silently skip a portion of the test
when running as root, rather than failing the whole test.
This regression was introduced with commit 84b5844d, 2009-09-03,
tests: simplify and fix a race in 2 tail --follow tests.
Good catch.
Looks
Hello. I ran the 7.2 test suite as root to get the results for the tests
required to be run as root, and got one error or failure. The following
is the console log produced by the failure. May 12, 2009. system:
Mandriva Powerpack 2007, i686, gcc 4.1.1, glibc 2.4, binutils 2.19.
John T
j
Jim Meyering wrote:
Kamil Dudka wrote:
On Thursday 26 of March 2009 18:00:47 Jim Meyering wrote:
diff --git a/tests/install/install-C-root b/tests/install/install-C-root
index df2843d..d5cc2de 100755
--- a/tests/install/install-C-root
+++ b/tests/install/install-C-root
@@ -23,6 +23,7 @@ fi
A test in make check-root fails for me. Since I usually don't make
check-root, it might have been around for a while. Full log follows:
$ sudo make -k check-root
cd tests make check-root SUBDIRS=
make[1]: Entering directory `/usr/local/src/coreutils-7.1.81-9b653/tests'
make check TESTS='chown
On Thursday 26 of March 2009 16:20:15 Sven Joachim wrote:
A test in make check-root fails for me. Since I usually don't make
check-root, it might have been around for a while. Full log follows:
The failure has been already reported:
http://lists.gnu.org/archive/html/bug-coreutils/2009-03
On Thursday 26 of March 2009 17:17:26 hggdh wrote:
hg...@xango2:/usr/src/buildd/coreutils/coreutils-git $ ls a echo 1
sudo src/ginstall -Cv a b echo 2 sudo src/ginstall -Cv -g2 a b
echo 3 sudo src/ginstall -Cv a b echo 4 sudo src/ginstall -Cv a b
1
[sudo] password for hggdh:
`a' -
On 2009-03-26 16:38 +0100, Kamil Dudka wrote:
On Thursday 26 of March 2009 16:20:15 Sven Joachim wrote:
A test in make check-root fails for me. Since I usually don't make
check-root, it might have been around for a while. Full log follows:
The failure has been already reported:
http
Sven Joachim wrote:
On Thursday 26 of March 2009 16:20:15 Sven Joachim wrote:
A test in make check-root fails for me. Since I usually don't make
check-root, it might have been around for a while. Full log follows:
...
That /usr/local/src is setgid src seems to be the crux. After removing
Blocks: 8 IO Block: 4096 regular file
Device: fc03h/64515d Inode: 278918 Links: 1
Access: (0755/-rwxr-xr-x) Uid: (0/root) Gid: ( 40/ src)
Access: 2009-03-26 11:42:43.0 -0500
Modify: 2009-03-26 11:42:43.0 -0500
Change: 2009-03-26 11:42
running check-root, it does not
fail if I manually run it. For the record, I am using the same glibc
you used on your try.
Right now I am tending to consider it some sort of environment thingy,
and leave it be. As time permits I will keep on trying to zero in this.
I am trying to free up some few
On Wednesday 18 March 2009 18:31:29 Kamil Dudka wrote:
Any idea how to reproduce the test failure?
Note I've tested it with the fresh Ubuntu installation and the updated one.
Kamil
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
On Thu, 12 Mar 2009 14:30:18 +0100
Kamil Dudka kdu...@redhat.com wrote:
Now just tested on the Gentoo Linux with similar configuration,
running the test install/install-C-root in the loop, still not able
to reproduce. Can I download a snapshot of Debian with your
configuration somewhere
On Tue, 10 Mar 2009 11:17:24 +0100
Kamil Dudka kdu...@redhat.com wrote:
Thank you for the report. Unfortunately I am not able to reproduce
it. Can you give me more details?
- architecture
- kernel
- glibc version (if any)
Sorry for the delay.
Thanks!
Now just tested on the Gentoo Linux with similar configuration, running the
test install/install-C-root in the loop, still not able to reproduce. Can I
download a snapshot of Debian with your configuration somewhere? Or is it
reproducible on the released one?
On Thursday 12 March 2009
On Thu, 12 Mar 2009 14:30:18 +0100
Kamil Dudka kdu...@redhat.com wrote:
Thanks!
Now just tested on the Gentoo Linux with similar configuration,
running the test install/install-C-root in the loop, still not able
to reproduce. Can I download a snapshot of Debian with your
configuration
On Monday 09 March 2009 15:18:25 hggdh wrote:
Every so often I run a make check, and (more eventually) a root make
check. After a git pull remake this morning, I ran a root check, and
got a failure on install-C-root.
Thank you for the report. Unfortunately I am not able to reproduce it. Can
Every so often I run a make check, and (more eventually) a root make
check. After a git pull remake this morning, I ran a root check, and
got a failure on install-C-root.
I am unsure on what was intended, or if even this failure is real (I am
not familiar, yet, with ginstall), but decided
I noticed that one of the root-only tests failed when
libcap-devel is not installed. This skips the test in that case.
From 7eb15e1020590ebc1f39e5679feea8f1106d241c Mon Sep 17 00:00:00 2001
From: Jim Meyering [EMAIL PROTECTED]
Date: Thu, 2 Oct 2008 15:54:36 +0200
Subject: [PATCH] tests: skip
Hello,
I have discovered that trying to run ls at the root of a drive (i.e. c:\)
errors out on directory listing for .
Cheers,
Mark
P.S. Otherwise a fantastic app.keep up the great work!
___
Bug-coreutils mailing list
Bug-coreutils
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Mark Toivanen on 9/29/2008 3:56 PM:
I have discovered that trying to run ls at the root of a drive (i.e. c:\)
errors out on directory listing for .
Copying and pasting the actual command line and result would have been
helpful
can't log in as root
am using directions from forums FAQ
bash: su-: command not foundis the error msg.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
On Sun, Aug 24, 2008 at 10:43 PM, jrl [EMAIL PROTECTED] wrote:
can't log in as root
am using directions from forums FAQ
bash: su-: command not foundis the error msg.
There should be a space before the dash, if you use it at all. For
more information see either
man su
or
info
On Sun, 2008-08-24 at 17:43 -0400, jrl wrote:
can't log in as root
am using directions from forums FAQ
bash: su-: command not foundis the error msg.
I am not sure what this has to do with coreutils, so you probably want
to pursue any other questions on an appropriate forum.
Just in case
FYI:
tests: avoid spurious make check-root failure
* README (Running tests as root): Also set PATH in suggested sudo
command. This avoids failure of at least tests/cp/cp-a-selinux
when the default PATH does not contain /sbin.
* tests/cp/cp-a-selinux: Don't
and one more:
tests: avoid a make check-root failure when mcstransd is running
* tests/misc/chcon: Skip this test if mcstransd seems to be running.
diff --git a/tests/misc/chcon b/tests/misc/chcon
index 3a61c69..74248a3 100755
--- a/tests/misc/chcon
+++ b/tests/misc/chcon
Bonjour,
Voilà, j'ai instll Wine pour essayer d'installer everest poker , ma
femme y joue pour le fun, et non pour de l'argent.Mai j'ai bien réussi à
l'enleveravecsynaptic... (libwine)..Sur son eeePc..Mais il reste le
dossier .wine et ses sous dossiers dans le fichier root.Comment
puis-je
I've just pushed a few change sets.
These two avoid failures that you'd see only when running make check
as root. The second is even less likely in that to trigger the failure
you'd have to be running make check as root on a system with SELinux
in enforcing mode, but with mcstransd deactivated
Just heard about this on IRC:
Avoid misinterpreting mgetgroups failure in running root-only tests.
* src/setuidgid.c (main): Don't misinterpret as size_t an error
return from mgetgroups. Reported by Theodoros V. Kalamatianos.
diff --git a/src/setuidgid.c b/src
the coreutils-6.9 archive, pretty sure now that there
is nothing disturbing in the paths, reconfigured, 'gmake' and
'gmake check' again: again same 2 errors as already reported
(tests/ls/color-dtype-dir as non-root, and tests/rm/no-give-up
as root).
Made your modification, re-run the tests (this time
[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)
getfacl -a d
getfacl -d d
Hi
Finally seen the reason for confusion why the test sometimes passes
and sometimes not:
If 'gmake check' is run as root from the tests/rm directory (such as
after when I make your suggested modifications) then the test always
passes because permissions
[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
1 - 100 of 138 matches
Mail list logo
