I 'm in ubuntu 7.04, when I input
man chmod
in a shell
the chmod man file displayed:
NAME
...
SYNOPSIS
...
DESCRIPTION
This manual page documents the GNU version of chmod.
should be
This manual page documents
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Thl Tha on 9/9/2007 8:03 AM:
This manual page documents the GNU version of chmod.
should be
This manual page documents is the GNU version of chmod.
Thanks for the report. However
Bob Proulx reported that chmod ignores dangling symlinks.
That's at odds with the documented behavior (affect referent
of each symlink), so I fixed it and added Bob's new test.
Here are the two latest change sets:
* Add a test: demonstrate that chmod ignores a dangling symlink
* chmod: don't
On Linux with coreutils 6.9, glibc 2.3.6, kernel 2.6.22.6, bash 3.2.35
I can do this:
#umask
0022
#mkdir testme
#chmod 02700 testme
#ls -ld testme
drwx--S--- 2 root root 4096 Sep 5 16:21 testme
#chmod 0700 testme
#ls -ld testme
drwx--S--- 2 root root 4096 Sep 5 16:21 testme
I was under
On May 15 2007 07:19, Jim Meyering wrote:
Paul Eggert [EMAIL PROTECTED] wrote:
Thanks for mentioning that. Here is a patch to the man page.
2007-05-14 Paul Eggert [EMAIL PROTECTED]
* man/chmod.x: Document chmod's behavior with setuid and setgid bits.
Remove misleading
John Cowan [EMAIL PROTECTED] writes:
However, if the directory has mode 6755 and you
do chmod 2755 dir, the mode remains 6755.
I hadn't thought of that example. It's a good illustration of an
unfortunate corner in the current rules. But I can't think of a
simple change to the rules
Jan Engelhardt [EMAIL PROTECTED] writes:
Since GNU is quite fond of `info`, do the info pages need fixing too?
No, thanks, they were updated long ago. But I had forgotten to fix
the man pages at one point when I changed the info pages and code.
___
is wildly different in this area. For example, on Solaris,
chmod 2755 DIR silently ignores the 2.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
.
+assumed to be leading zeros.
The first digit selects the set user ID (4) and set group ID (2) and
restricted deletion or sticky (1) attributes. The second digit
selects permissions for the user who owns the file: read (4), write (2),
@@ -72,6 +71,30 @@ In contrast,
.B chmod
ignores symbolic links
do chmod 2755 dir, the mode remains 6755. This violates the
Law of Least Astonishment, I think.
I had earlier thought that it doesn't matter, because setuid
doesn't mean anything on directories in most *ix variants, but
on FreeBSD it causes files created in the directory to be
owned
Paul Eggert [EMAIL PROTECTED] wrote:
Thanks for mentioning that. Here is a patch to the man page.
2007-05-14 Paul Eggert [EMAIL PROTECTED]
* man/chmod.x: Document chmod's behavior with setuid and setgid bits.
Remove misleading implication about leading zero. Problem
Cc'ed bug-coreutils.
The following bug affects at least:
coreutils 6.4 (used in opensuse 10.2 - open a bug report here)
coreutils 6.9
On May 12 2007 15:16, J G Miller wrote:
From: J G Miller
To: Jan Engelhardt
Subject: re: chmod octal form of sgid/suid
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jan Engelhardt on 5/12/2007 8:50 AM:
Cc'ed bug-coreutils.
The following bug affects at least:
coreutils 6.4 (used in opensuse 10.2 - open a bug report here)
coreutils 6.9
$ mkdir /dev/shm/me
$ strace -e chmod chmod 0755 me
Eric Blake scripsit:
chmod, install, and mkdir now preserve a directory's set-user-ID and
set-group-ID bits unless you explicitly request otherwise.
Well and good, but it seems to me that writing an explicit 0 actually
does make an explicit request.
To clear the bits, mention them
On May 12 2007 12:07, Eric Blake wrote:
According to Jan Engelhardt on 5/12/2007 8:50 AM:
Cc'ed bug-coreutils.
The following bug affects at least:
coreutils 6.4 (used in opensuse 10.2 - open a bug report here)
coreutils 6.9
$ mkdir /dev/shm/me
$ strace -e chmod chmod 0755 me
chmod(me
Maybe following entry in the coreutils-6.9/README file is related
to the umask / chmod interaction, and maybe the may fail bit in there
would go away if all 'mkdir' or 'touch' in all tests are followed
by a 'chmod' that explicitly sets all bits (not just a few of them).
Greets,
Arto
from
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Your mail client appears to add a space after every -, which made it
somewhat awkward to read.
According to benjamin kravanja on 5/4/2007 5:30 AM:
Hallo,
1 - seems to be a critical bug in chmod,
if superuser flags were set, you can not reset
Eric Blake wrote:
#$ echo - e \015\033[- 1Cxxx starts string xxx at position 0, ok
Using \015 as the argument to echo is not portable shell; you should use
\\015 or '\015' instead.
Using -e isn't portable shell either, as POSIX requires echo to
recognize no options, but instead treat
[EMAIL PROTECTED] (Matthew M. Boedicker) wrote:
The --preserve-root failsafe in chown, chmod, etc. does not exit when it
should. It prints a warning and continues to recurse. ROOT_DEV_INO_WARN
should pass a non-zero value as the first argument to error() to exit.
Thanks again. I've fixed
Hope this is not a dupe. I sent this before I subscribed but it didn't seem
to go through.
The --preserve-root failsafe in chown, chmod, etc. does not exit when it
should. It prints a warning and continues to recurse. ROOT_DEV_INO_WARN
should pass a non-zero value as the first argument to error
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
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
looks like doing `chmod 0755` no longer clears sticky bits ... for example:
$ tar xf coreutils-6.3.tar.bz2
$ cd coreutils-6.3
$ ./configure
$ make -C lib
$ make -C src chmod
$ mkdir foo
$ stat -c%a foo
755
$ ./src/chmod -v 2755 foo
mode of `foo' changed to 2755 (rwxr-sr-x)
$ stat -c%a foo
2755
On Saturday 30 September 2006 19:07, Mike Frysinger wrote:
looks like doing `chmod 0755` no longer clears sticky bits ...
seems to arise from lib/modechange.c:mode_adjust() ... particularly:
mode_t omit_change =
(dir ? S_ISUID | S_ISGID : 0) ~ changes-mentioned;
omit_change here is set
Mike Frysinger [EMAIL PROTECTED] writes:
looks like doing `chmod 0755` no longer clears sticky bits ... for example:
Yes, that's mentioned in the NEWS file. It says:
chmod, install, and mkdir now preserve a directory's set-user-ID and
set-group-ID bits unless you explicitly request
Mike Frysinger [EMAIL PROTECTED] writes:
i guess this is allowed by spec huh ?
Yes. The last sentence in the extract that you quoted clearly allows
the current behavior. The area is not standardized that closely, so
we tried to do the right thing. It was discussed in several threads,
e.g.,
mwoehlke [EMAIL PROTECTED] writes:
You are looking for this, yes?
Yes, that sort of thing.
10487 chmodCALL chmod(0x2800600,0x1a4)
10487 chmodNAMI .
10487 chmodRET chmod 0
10487 chmodCALL chmod(0x2800600,0x1a4)
10487 chmodNAMI b
10487 chmodRET chmod 0
Paul Eggert wrote:
mwoehlke [EMAIL PROTECTED] writes:
10487 chmodCALL chmod(0x2800600,0x1a4)
10487 chmodNAMI .
10487 chmodRET chmod 0
10487 chmodCALL chmod(0x2800600,0x1a4)
10487 chmodNAMI b
10487 chmodRET chmod 0
10487 chmodCALL close(0x1)
10487
mwoehlke [EMAIL PROTECTED] wrote:
I'll investigate the other failures, but if I can demonstrate that a:
the OS is broken, and b: the OS's version of the same utility is
similarly broken, I'll just leave my reports at that (unless someone
objects to this plan).
Fine by me, especially since I'm
Paul Eggert wrote:
[for chmod/no-x]
+ mkdir -p a/b
+ cd a
+ chmod a-x . b
+ fail=1
This indicates that chmod a-x . b succeeded, but it should have
failed because it should have made . unsearchable before attempting
to access b (aka ./b). Again, can you please try to see what
system
Paul Eggert [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
Regarding your conceptually separate change that adds the check
for fts_close failure, you're welcome to add it back, especially
if you can come up with a test case that triggers it.
Those changes aren't needed any
Jim Meyering [EMAIL PROTECTED] writes:
Regarding your conceptually separate change that adds the check
for fts_close failure, you're welcome to add it back, especially
if you can come up with a test case that triggers it.
Those changes aren't needed any more, since the programs are about to
Paul Eggert [EMAIL PROTECTED] wrote:
While testing the new mkdir -p stuff I noticed a bug in chmod:
it doesn't operate left-to-right as tradition and POSIX require:
$ mkdir d d/e
$ chmod 0 d/e d
$ chmod a+rwx d d/e
chmod: cannot access `d/e': Permission denied
The last chmod
Update of bug #11638 (project coreutils):
Status:None = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #1:
Thanks for the
While testing the new mkdir -p stuff I noticed a bug in chmod:
it doesn't operate left-to-right as tradition and POSIX require:
$ mkdir d d/e
$ chmod 0 d/e d
$ chmod a+rwx d d/e
chmod: cannot access `d/e': Permission denied
The last chmod should succeed, but it fails.
I installed
(and therefore can't open it) but POSIX still requires mkdir to chmod
it in this case. Hence the patch you submitted here isn't quite
right, since it sometimes gives up when it shouldn't. We have fixed
mkdir a different way in coreutils test version 6.1
ftp://alpha.gnu.org/gnu/coreutils/coreutils-6.1.tar.gz
URL:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=17427
Summary: CVE-2005-1039, chmod race in mkdir, mkfifo, mknod
Project: GNU Core Utilities
Submitted by: None
Submitted on: Monday 08/14/2006 at 06:29 UTC
Jim Meyering [EMAIL PROTECTED] writes:
As you've guessed, #2 is the one I prefer.
OK, I implemented that by installing the following. This should also
fix the test case problems that Bob reported.
2006-07-28 Paul Eggert [EMAIL PROTECTED]
* NEWS: chmod now preserves setuid
Jim Meyering [EMAIL PROTECTED] writes:
If we remove this feature, I'd like to change things to be 100%
consistent with Solaris, and to preserve the setgid bit even if the
user says chmod 0755 DIR.
I think that is the right approach.
I started to implement this, but oops! I now see that I
Eric Blake [EMAIL PROTECTED] writes:
Should we document chmod 00500 dir as an explicit way to clear the bit,
or just require a textual mode string?
Are you proposing that a directory's setgid bit be preserved if 4 or
fewer octal digits are used, and be set or cleared if 5 or more are
used
Paul Eggert wrote:
* tests/cp/fail-perm: Use chmod 0500 rather than chmod 500.
--- tests/cp/fail-perm28 May 2006 12:11:35 - 1.10
+++ tests/cp/fail-perm25 Jul 2006 18:37:23 -
-chmod 500 D || framework_failure=1
+chmod 0500 D || framework_failure=1
Did
** Changes in behavior
The tests/mkdir/special-1 test also now fails.
Summary: drwxr-s-wT != drwxr-x-wT
Proposed change:
-set_mode_string=u=rwx,g=rx,o=w,go+t
+set_mode_string=u=rwx,g=rx,o=w,go+t,ug-s
Drift: What is the meaning of g+t in this context?
Bob
env VERBOSE=yes make check
[EMAIL PROTECTED] (Bob Proulx) wrote:
Paul Eggert wrote:
* tests/cp/fail-perm: Use chmod 0500 rather than chmod 500.
--- tests/cp/fail-perm 28 May 2006 12:11:35 - 1.10
+++ tests/cp/fail-perm 25 Jul 2006 18:37:23 -
-chmod 500 D || framework_failure=1
+chmod 0500
Paul Eggert [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
If we remove this feature, I'd like to change things to be 100%
consistent with Solaris, and to preserve the setgid bit even if the
user says chmod 0755 DIR.
I think that is the right approach.
I started
Paul Eggert [EMAIL PROTECTED] wrote:
I don't think it is a good idea to make
chmod 500 dir
behave differently than
chmod 0500 dir
That simply seems too subtle and will be too confusing to most people.
It is a bit subtle, and if there is consensus on this I'd be willing
to remove
Paul Eggert wrote:
Bob Proulx writes:
Contrary to the statement above my testing shows that FreeBSD chmod
does not behave this way.
OK, thanks, clearly NEWS (at least :-) needs to get fixed.
:-) Agreed.
Also I applaud your efforts to make working with setgid directories
nicer
ChangeLog:
2006-07-16 Paul Eggert [EMAIL PROTECTED]
* NEWS: chmod, install, and mkdir now leave setgid and setuid bits
of directories alone unless you specify them explicitly.
install and mkdir now implement X correctly.
install now creates parent directories
[EMAIL PROTECTED] (Bob Proulx) writes:
Contrary to the statement above my testing shows that FreeBSD chmod
does not behave this way.
OK, thanks, clearly NEWS (at least :-) needs to get fixed.
The behavior I observe on OpenBSD 3.9 is that sometimes the setgid bit
is preserved, and sometimes
The chmod man page seems to incorrectly report the behavior of the
sticky bit on directories.
man chmod reports, in part:
STICKY DIRECTORIES
When the sticky bit is set on a directory, files in that
directory may
be unlinked or renamed only by root or their owner
:55 - 1.6
+++ man/chmod.x 23 Jul 2006 01:25:41 -
@@ -1,42 +1,55 @@
[NAME]
-chmod \- change file access permissions
+chmod \- change file mode bits
[DESCRIPTION]
This manual page
documents the GNU version of
.BR chmod .
.B chmod
-changes the permissions of each given file
Vasek Potocek [EMAIL PROTECTED] wrote:
I think I have found some bug in chmod.
...
touch a
mkdir b
touch c
cd b
chmod a-x ../*
makes a segmentation fault.
The versions are:
chmod (GNU coreutils) 5.93
Fedora Core 5 on a i686 (2.6.16-1.2111_FC5)
glibc 2.4
Thank you for the report
Hello,
I think I have found some bug in chmod. Maybe it is more general, but I didn't manage (and didn't try hard) to
reconstruct it using different utilities. The sequence (alphabetical order is important)
touch a
mkdir b
touch c
cd b
chmod a-x ../*
makes a segmentation fault.
Though it may
Thank you for your detailed response. I am learning a lot here. I'll try
the sgid/umask approach.
Mike K.
[EMAIL PROTECTED] (Bob Proulx) wrote: -
To: [EMAIL PROTECTED]
From: [EMAIL PROTECTED] (Bob Proulx)
Date: 04/06/2006 11:33PM
cc: bug-coreutils@gnu.org
Subject: Re: chmod
Eric Blake
/group/permissions and a different method I can essentially accomplish
what chmod says is not permitted.
Consider the following:
[EMAIL PROTECTED] test]$ ls -al
total 12
drwxrwxr-x 2 mike www 4096 Apr 6 12:03 .
drwxr-x--- 11 mike www 4096 Apr 6 12:03 ..
-rw-rw-r-- 1 sarah www 15 Apr 6 12
user/group/permissions and a different method I can essentially accomplish
what chmod says is not permitted.
Because POSIX says so.
http://www.opengroup.org/onlinepubs/009695399/utilities/chmod.html
Only a process whose effective user ID matches the user ID of the file, or
a process
of a few extra bits set in the inode to say that
they are actually a directory. The ownership of the parent directory
is not involved in whether you can chmod files. Consider this example.
mkdir protected
touch protected/testfile
sudo chown -R nobody:nogroup protected
ls -dl protected protected
On Mon, 2006-01-09 at 20:55 +0100, Jim Meyering wrote:
Stavros Passas [EMAIL PROTECTED] wrote:
...
more,on coreutils 5.93 the output on the same command is:
chmod: fts_read failed: Permission denied
*** glibc detected *** chmod: double free or corruption (fasttop):
Thanks
]
Avoid the double-free (first in fts_read, second in fts_close) that
would occur when an `active' directory is made inaccessible (e.g.,
via chmod a-x) during a traversal.
* fts.c (fts_read): After a failed fchdir, update sp-fts_cur
before returning. Reproduce this failure
Hello,
I'm not 100% sure if it a actual bug or not,
but if someone use chmod with wrong arguments,
he can take a sagmentation fault.
Further Informations:
System: i386,Linux 2.6.12
shell: bash 3.00.16
Version of coreutils: 5.2.1
Tested on Fedora3,Fedora4,Slackware
Command to take the bug
Stavros Passas [EMAIL PROTECTED] wrote:
...
more,on coreutils 5.93 the output on the same command is:
chmod: fts_read failed: Permission denied
*** glibc detected *** chmod: double free or corruption (fasttop):
Thanks for the report.
However, I'm not able to reproduce that with 5.93
-penguin $ mkdir -p {a,b,c}/{c,d,e}/{c,d,e}
529-penguin $ valgrind chmod 600 `find ./`
==9774== Memcheck, a memory error detector for x86-linux.
==9774== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==9774== Using valgrind-2.4.0, a program supervision framework for x86-linux.
==9774
Paul Eggert [EMAIL PROTECTED] wrote:
...
We could get fancier and use fchmod for readable directories and for
readable or writeable regular files, falling back on lchmod for
everything else; but this still suffers from the same race conditions
that lchmod suffers from, and I'm not sure it's
Paul Eggert [EMAIL PROTECTED] wrote:
For mkdir, mknod, and mkfifo, how about this idea instead? If -m is
used, use only the umask to set the file permission bits; do not use
chmod (or fchmod) at all. That way, there won't be any race
conditions at all.
Do other versions of these tools work
I installed the following to make coreutils act like FreeBSD with
respect to when chmod() is invoked, along the lines I suggested
earlier today. I noticed several other places where chmod can safely
be replaced by lchmod, and did those too, as that makes the programs
slightly safer
I noticed a problem with chown.c (when CHOWN_MODIFIES_SYMLINK) and
chmod-safer.c. If the file being chmod'ed or chown'ed is a special
file, opening it can cause undesirable side effects. For example, it
might cause a tape drive to be rewound.
[ In case it's not obvious to the readers, here
be cured with sticky
directories.
For mkdir, mknod, and mkfifo, how about this idea instead? If -m is
used, use only the umask to set the file permission bits; do not use
chmod (or fchmod) at all. That way, there won't be any race
conditions at all.
I went back and reread POSIX, and it seems to me
I noticed a problem with chown.c (when CHOWN_MODIFIES_SYMLINK) and
chmod-safer.c. If the file being chmod'ed or chown'ed is a special
file, opening it can cause undesirable side effects. For example, it
might cause a tape drive to be rewound.
Also, the current implementations of mkdir, mkfifo
Jim,
here is a small chmod input validation fix.
Cheers,
Andreas.
From: Andreas Gruenbacher [EMAIL PROTECTED]
Subject: chmod input parsing fix
A command like ``chmod 0759 /mnt/x'' doesn't produce an error
message even though 0759 is not a valid octal number.
Index: coreutils-5.90/lib
Thanks a lot!
I've applied that and added a test.
2005-10-20 Jim Meyering [EMAIL PROTECTED]
* tests/chmod/octal: New file/test, to exercise today's
lib/modechange.c fix.
* tests/chmod/Makefile.am (TESTS): Add octal.
* NEWS: Mention this chmod fix as well
in bash:
:~/tmp$ ls -l
insgesamt 8
drwxr-xr-x 2 chris chris 4096 2005-10-20 09:28 dir0
:~/tmp$ ls -l dir0
insgesamt 4
-rwxr--r-- 1 chris chris 5 2005-10-20 09:28 foo.txt
:~/tmp$ chmod -R u+x *.txt
chmod: Zugriff auf „*.txt“ nicht möglich: Datei oder Verzeichnis nicht
gefunden
in zsh
Christian Spielberger wrote:
:~/tmp$ ls -l
insgesamt 8
drwxr-xr-x 2 chris chris 4096 2005-10-20 09:28 dir0
:~/tmp$ ls -l dir0
insgesamt 4
-rwxr--r-- 1 chris chris 5 2005-10-20 09:28 foo.txt
:~/tmp$ chmod -R u+x *.txt
chmod: Zugriff auf „*.txt“ nicht möglich: Datei oder Verzeichnis
I installed this patch so that 'cp -p' prefers to use fchown to chown,
and fchmod to chmod, when copying regular files. The f* versions
ought to be a bit faster since they needn't resolve file names.
I left a FIXME for preserving st_author, as I don't know how to
preserve that on the Hurd
On Sun, Jul 17, 2005 at 12:21:35PM +0100, James Youngman wrote:
Adding the -h option [...]
I haven't implemented this yet.
Rats, I didn't proof-read the patch. This part should not (yet) be in there:
--- src/chmod.c 29 Jun 2005 16:27:37 - 1.113
+++ src/chmod.c 17 Jul
(i.e. the mailing list) how the -h and
-L options of chmod interact, both when -R is given and when it is
not? Thanks.
Regards,
James.
Index: src/chmod.c
===
RCS file: /cvsroot/coreutils/coreutils/src/chmod.c,v
retrieving revision
On Fri, Jul 15, 2005 at 12:18:35PM -0700, Dave Yost wrote:
The chmod on Mac OS X (which is probably same as one of the BSDs) has
better functionality and a much better man page. GNU should catch up.
Dave
Dave,
Thanks for your interest. Maybe you're right. Please explain in more
detail
At 10:28 AM +0100 2005-07-16, James Youngman wrote:
On Fri, Jul 15, 2005 at 12:18:35PM -0700, Dave Yost wrote:
The chmod on Mac OS X (which is probably same as one of the BSDs) has
better functionality and a much better man page. GNU should catch up.
Dave
Dave,
Thanks for your interest
On Sat, Jul 16, 2005 at 12:26:28PM -0700, Dave Yost wrote:
At 10:28 AM +0100 2005-07-16, James Youngman wrote:
Thanks for your interest. Maybe you're right. Please explain in more
detail why you think that the MacOS X implementation of chmod(1) is
superior to the GNU coreutils
Dave Yost [EMAIL PROTECTED] writes:
The chmod on Mac OS X (which is probably same as one of the BSDs) has
better functionality and a much better man page. GNU should catch up.
I assume you're talking about the -H, -h, -L, -P options. You're
right, these would be nice to add to coreutils. Do
The chmod on Mac OS X (which is probably same as one of the BSDs) has
better functionality and a much better man page. GNU should catch up.
Dave
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug
Hi,
GNU mv is subject to race-condition attack when it moves files across
filesystems. The problem is that it open() the new file, copies the
content, then close() it, and call chown(), chmod() and setxattr() on
the new path. This is unsafe because the path used to set the file
attributes could
[EMAIL PROTECTED] (Gaëtan LEURENT) writes:
[Sorry for not sending a patch to better explain how to do, but the code
is a bit too hairy for me].
Thanks for reporting that. Patches would be most welcome. Perhaps
you can help recruit someone who has the time and expertise to write them?
If you
Peter Kratzer wrote:
some of my users are encountering random errors with the chmod command.
The
errors are not exactly reproducible, so I cannot even narrow down the
circumstances of their occurrance.
Problems like that can be disheartening and hard to track down. I saw
James' question
Hello friends,
some of my users are encountering random errors with the chmod command. The
errors are not exactly reproducible, so I cannot even narrow down the
circumstances of their occurrance.
What else do I know:
- Following message occurs: chmod: changing permissions of
`filename
On Wed, Jun 08, 2005 at 05:33:59PM +0200, Peter Kratzer wrote:
Hello friends,
some of my users are encountering random errors with the chmod
command. The errors are not exactly reproducible, so I cannot even
narrow down the circumstances of their occurrance.
- What operating systems
James Youngman [EMAIL PROTECTED] wrote on 2005-06-08 18:01:26:
On Wed, Jun 08, 2005 at 05:33:59PM +0200, Peter Kratzer wrote:
Hello friends,
some of my users are encountering random errors with the chmod
command. The errors are not exactly reproducible, so I cannot even
narrow down
Peter Kratzer wrote:
some of my users are encountering random errors with the chmod command. The
errors are not exactly reproducible, so I cannot even narrow down the
circumstances of their occurrance.
Problems like that can be disheartening and hard to track down. I saw
James' question
Peter Kratzer [EMAIL PROTECTED] writes:
They are using NFS (NAS filer).
Possibly you're running into ACL problems. Are there any ACLs in use
anywhere on that file system? If so, that can prevent the chmod
system call from succeeding, and this will cause the chmod command
to fail as well
Andras S. Haramasz [EMAIL PROTECTED] writes:
VERNOSE=yes make check TESTS=no-x check.no-x.VERBOSE 21
cat check.no-x.VERBOSE
make check-TESTS
make[1]: Entering directory
`/usr/local/src/GNU/coreutils-5.2.1/coreutils-5.2.1/
tests/chmod'
./no-x: cannot create temp file for here document
./no-x: cannot create temp file for here document: Permission denied
I think we have been having several builders lately with severely
broken systems. Perhaps we should create some tests not for coreutils
itself but instead for the system? Things like /dev/null readable and
writable and the
Andras S. Haramasz [EMAIL PROTECTED] writes:
It appears to me that this version (5.3.0) gives me the same error too.
It's failing in the chmod/no-x test, so let's try to figure out why.
Can you please try the following commands?
cd tests/chmod
VERBOSE=yes make check TESTS=no-x
For comparison
To Whom It May Concern:
Uname Linux two 2.4.30 #6 SMP Mon May 23 09:10:01 EDT 2005 i686
Thanks for you prompt attention.
Regards,
Andras S. Haramasz
make.check.OUT
Description: Binary data
___
Bug-coreutils mailing list
For quite some time I've been annoyed that chmod -w file can leave
the file writeable afterwards, if your umask is restrictive. You're
supposed to use chmod a-w file if you really want the file to be
unwriteable.
This is a common trap for novices to fall into, and I think it'd be
better if chmod
This is a common trap for novices to fall into, and I think it'd be
better if chmod diagnosed the mistake, in addition to performing the
requested action. I just checked POSIX, and it allows chmod to
diagnose errors like chmod -w file so I installed the following
patch.
It took me a while
[EMAIL PROTECTED] (Eric Blake) writes:
Other questions, though - with our extension options, should we interpret
`chmod -w a+x foo' the same as `chmod -- -w ./a+x ./foo' or like
`chmod -- -w,a+x ./foo'?
It's been the former for a while; I guess that's OK.
POSIX allows modes that look like
I installed this as a minor simplification to modechange. The only
change visible to coreutils users is that a few invalid usages like
chmod +1 file and chmod ' 1' file are now caught.
2005-05-01 Paul Eggert [EMAIL PROTECTED]
* NEWS: chmod +1 file is now diagnosed.
* lib
I got Argument list too long error when I try to chmod 0600 * a /Maildir
which contains thousands of files. How to do?
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
On Thu, 28 Apr 2005, Rcipapo wrote:
I got Argument list too long error when I try to chmod 0600 * a /Maildir
which contains thousands of files. How to do?
Read the FAQ?
http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Argument-list-too-long
Cheers,
Phil
While I was in the chmod-fixing business, I discovered some minor
glitches in the documentation, and fixed them as follows. Most of
this is about modernization of the sticky bit, and clarification of
which things are POSIX and which are GNU extensions.
2005-04-28 Paul Eggert [EMAIL PROTECTED
I found I could get away with chmod +x file. Perhaps catch it.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Dan Jacobson [EMAIL PROTECTED] writes:
I found I could get away with chmod +x file. Perhaps catch it.
POSIX requires support for that. It's weird, but it's probably not
worth diagnosing.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
301 - 400 of 422 matches
Mail list logo
