bug#10311: RFE: Give chmod a "-h" option as well

/ownership in a directory where an evil user could create a symlink to e.g. /etc/shadow. Attempting chmod -R g+w /home/groups/evilgroup is still a risk, and would necessity a more long-winded command involving find(1). It would therefore be welcome that chmod receive an -h option that just skips

bug#11108: [PATCH] chmod: fix symlink race condition

On 28/03/2012 21:28, Paul Eggert wrote: On 03/28/2012 01:13 PM, Jim Meyering wrote: $ ./chmod u+w f ./chmod: changing permissions of 'f': Operation not supported Yeouch. I undid the change for now. Hmm, why did "make check" work for me? I'll have to investigate later, ala

bug#60291: chmod a-r does not fail for vfat

On 12/23/22 17:09, Krzysztof Żelechowski wrote: chmod a-r a.txt && stat a.txt Expected: chmod: unsupported permissions Got: -r--r--r-- This is wrong because the command chmod had failed to set the permissions The chmod command is doing the right thing; the problem lies elsewhere. Run

bug#60291: chmod a-r does not fail for vfat

chmod (GNU coreutils) 9.1 x86_64 cd /tmp dd if=/dev/zero of=fd0 count=2880 echo 'drive a: file="/tmp/fd0' >.mtoolsrc mformat a: umask 0022 udisksctl loop-setup -f fd0 udisks mount /dev/loop3p1 cd /run/media/dell/1F9D-2F6C echo >a.txt chmod a-r a.txt && stat a.t

bug#55487: chmod to +w is not defaulting to ALL target in Debian 11.3

Interesting. On Tue, May 17, 2022 at 9:38 PM Paul Eggert wrote: > On 5/17/22 10:51, Corey H wrote: > > sudo chmod +w /etc/whatever/whatever.conf #doesn't work > > sudo chmod a+w /etc/whatever/whatever.conf #does work > > It sounds like you're misunderstanding what "c

bug#55487: chmod to +w is not defaulting to ALL target in Debian 11.3

On 5/17/22 10:51, Corey H wrote: sudo chmod +w /etc/whatever/whatever.conf #doesn't work sudo chmod a+w /etc/whatever/whatever.conf #does work It sounds like you're misunderstanding what "chmod +w" means. It doesn't mean "turn on all the w bits". It means "t

bug#55487: chmod to +w is not defaulting to ALL target in Debian 11.3

in Debian 8.32-4+b1 (Debian 11.3) chmod +w isn't working right. sudo mkdir /etc/whatever sudo touch /etc/whatever/whatever.conf sudo chmod +w /etc/whatever/whatever.conf #doesn't work sudo chmod a+w /etc/whatever/whatever.conf #does work #in man chmod # it states "If none of these are

bug#53262: chmod 9.0 failing, where 8.29 succeeds - but no error message

On 15/01/2022 01:09, Paul Eggert wrote: Thanks for reporting that. This is a duplicate of bug#50784[1], which was fixed[2] in September. Perhaps we should generate a new Coreutils soon, since this bug has been reported three times now. [1]: https://bugs.gnu.org/50784 [2]:

bug#53262: chmod 9.0 failing, where 8.29 succeeds - but no error message

Thanks for reporting that. This is a duplicate of bug#50784[1], which was fixed[2] in September. Perhaps we should generate a new Coreutils soon, since this bug has been reported three times now. [1]: https://bugs.gnu.org/50784 [2]:

bug#53262: chmod 9.0 failing, where 8.29 succeeds - but no error message

Hello, we found a case, where chmod from coreutils 9.0 fails (exit value 1), while the one from 8.29 succeeds. (exit value 0) Unfortunately, no (error) message is given, just the exit value is 0 and 1 respectively. Here is the example: == 8.29: fine >chmod --version chmod (

bug#50791: Recursive chmod exit status in coreutils-9.0

Pádraig Brady wrote: CH_NOT_APPLIED is smaller than CH_NO_CHANGE_REQUESTED in the current enum ordering, so we skip this block as expected for the ignored symlink case. Sorry, you're quite right; I missed that. Best wishes, Chris.

bug#50791: Recursive chmod exit status in coreutils-9.0

On 25/09/2021 07:07, Chris Webb wrote: Thanks for the analysis and patch. I've already pushed a very similar patch at: https://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=e8b56ebd5 Many thanks! With the above fix, do we also need something like @@ -300,7 +300,7 @@ process_file (FTS

bug#50791: Recursive chmod exit status in coreutils-9.0

> Thanks for the analysis and patch. > I've already pushed a very similar patch at: > https://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=e8b56ebd5 Many thanks! With the above fix, do we also need something like @@ -300,7 +300,7 @@ process_file (FTS *fts, FTSENT *ent)

bug#50791: Recursive chmod exit status in coreutils-9.0

forcemerge 50791 50784 stop On 24/09/2021 22:16, Chris Webb wrote: Since bbb19b, chmod has started returning EXIT_FAILURE after skipping a symlink during a recursive change. This affects chmod in the newly released coreutils-9.0 vs the previous coreutils-8.32 and older versions: # mkdir t

bug#50784: coreutils 9.0 sometimes gets spurious failures in chmod -R

On 24/09/2021 22:42, Daniel Schepler wrote: On Fri, Sep 24, 2021 at 1:02 PM Pádraig Brady wrote: Could you try with the following untested diff: Tested equivalent patch is attached. Yes, with chmod-fix-symlink-exit.patch applied and the resulting packages installed for testing, the issue

bug#50784: coreutils 9.0 sometimes gets spurious failures in chmod -R

On 9/24/21 22:02, Pádraig Brady wrote: Tested equivalent patch is attached. Nice small patch. Maybe it's worth documenting in the enum where the "bad range" starts against which the code later tests? Furthermore, I think it's worth adding a NEWS entry and mentioning that this bug has been

bug#50791: Recursive chmod exit status in coreutils-9.0

Since bbb19b, chmod has started returning EXIT_FAILURE after skipping a symlink during a recursive change. This affects chmod in the newly released coreutils-9.0 vs the previous coreutils-8.32 and older versions: # mkdir t # cd t # : > foo # ln -s foo bar # chmod-8.32 -v -R

bug#50784: coreutils 9.0 sometimes gets spurious failures in chmod -R

On Fri, Sep 24, 2021 at 1:02 PM Pádraig Brady wrote: > > Could you try with the following untested diff: > > Tested equivalent patch is attached. Yes, with chmod-fix-symlink-exit.patch applied and the resulting packages installed for testing, the issue does appear to be resolved

bug#50784: coreutils 9.0 sometimes gets spurious failures in chmod -R

On 24/09/2021 20:29, Pádraig Brady wrote: On 24/09/2021 19:21, Daniel Schepler wrote: After I upgraded my system (locally built) to coreutils 9.0, I noticed that my lightly modified sbuild started getting build failures when it tries to run "chmod -R g+w /<>" (as root) in

bug#50784: coreutils 9.0 sometimes gets spurious failures in chmod -R

On 24/09/2021 19:21, Daniel Schepler wrote: After I upgraded my system (locally built) to coreutils 9.0, I noticed that my lightly modified sbuild started getting build failures when it tries to run "chmod -R g+w /<>" (as root) in the chroot. I'm not sure exactly what comb

bug#50784: coreutils 9.0 sometimes gets spurious failures in chmod -R

After I upgraded my system (locally built) to coreutils 9.0, I noticed that my lightly modified sbuild started getting build failures when it tries to run "chmod -R g+w /<>" (as root) in the chroot. I'm not sure exactly what combination of files triggers the error, but I'm a

bug#50070: chmod reads uninitialized variables when fts_info is an error and -v is set, leading to random error messages

Thanks for reporting the bug. I installed the attached patch to fix it. >From af4711d5dc15f0c014bfd9c92f4eadedb89f732f Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 15 Aug 2021 21:29:38 -0700 Subject: [PATCH] chmod: fix use of uninitialized var if -v Problem reported by Michael Deber

bug#50070: chmod reads uninitialized variables when fts_info is an error and -v is set, leading to random error messages

Hi, I noticed that when running chmod with -v on a dangling symlink the error message is somewhat random: > ln -s file-that-does-not-exist lnk > chmod -w lnk -v > chmod: cannot operate on dangling symlink 'lnk' > failed to change mode of 'lnk' from (-) to 777

bug#41554: chmod allows removing x bit on chmod without a force flag, which can be inconvenient to recover from

pposed to this thought-experiment situation. > "chmod a-x $(which chmod)" not a particularly likely thing for a user to > try to do directly, but it is conceivable for some sort of script to > attempt it by accident because of a bug, and it would make the system > inconvenient to recov

bug#41554: chmod allows removing x bit on chmod without a force flag, which can be inconvenient to recover from

On Mai 26 2020, Will Rosecrans wrote: > "chmod a-x $(which chmod)" not a particularly likely thing for a user to > try to do directly, but it is conceivable for some sort of script to > attempt it by accident because of a bug, and it would make the system > i

bug#41554: chmod allows removing x bit on chmod without a force flag, which can be inconvenient to recover from

On 5/26/20 6:30 PM, Will Rosecrans wrote: > The underlying safety logic is similar to that behind the > existing "--(no-)preserve-root" I think not. There are all sorts of other things one shouldn't chmod either, but we can't and shouldn't maintain a long list. Let's stop with "/".

bug#41554: chmod allows removing x bit on chmod without a force flag, which can be inconvenient to recover from

Based on an inane interview question that was discussed here on Twitter: https://twitter.com/QuinnyPig/status/1265286980859908102 "chmod a-x $(which chmod)" not a particularly likely thing for a user to try to do directly, but it is conceivable for some sort of script to attempt it b

bug#23853: chmod can unset sticky bits using octet format

close 23853 stop (triaging old bugs) On 2016-06-27 8:13 a.m., Eric Blake wrote: On 06/26/2016 06:56 PM, westlake wrote: contrary to documentation, chmod can otherwise clear sticky bits using the octet notation but by using a 5th octal [...] The behavior of the 5th octal to intentionally

bug#30477: [PATCH] chmod chown chgrp: added --exclude-files and --exclude-directories

tags 30477 wontfix severity 30477 wishlist close 30477 stop (triaging old bugs) On Sat, Feb 17, 2018 at 01:30:24PM -0800, Pádraig Brady wrote: > > Such functionality has been discussed previously at: > https://www.gnu.org/software/coreutils/rejected_requests.html#chmod > Given th

bug#7523: chmod example in docs

tags 7523 moreinfo notabug close 7523 stop (triaging old bugs) With no further comments and no improvement suggestions in 8 years, I'm closing this bug. -assaf

bug#11043: chmod - new feature - restore default mode regarding the umask value

tags 11043 fixed close 11043 stop On 15/10/18 05:55 PM, Paul Eggert wrote: On 10/15/18 9:28 AM, Assaf Gordon wrote: On 27/03/12 09:54 AM, Paul Eggert wrote: Here's a proposed patch to document the already-existing feature on this point. Seems like the patch in https://bugs.gnu.org/11043#14

bug#11043: chmod - new feature - restore default mode regarding the umask value

On 10/15/18 9:28 AM, Assaf Gordon wrote: On 27/03/12 09:54 AM, Paul Eggert wrote: Here's a proposed patch to document the already-existing feature on this point. Seems like the patch in https://bugs.gnu.org/11043#14 was ready but never committed. OK to commit? Yes, and thanks.

bug#11043: chmod - new feature - restore default mode regarding the umask value

(triaging old bugs) On 27/03/12 09:54 AM, Paul Eggert wrote: Here's a proposed patch to document the already-existing feature on this point. Seems like the patch in https://bugs.gnu.org/11043#14 was ready but never committed. OK to commit? -assaf

bug#32772: TOCTOU bug in chmod

Thanks for the correction, I should have not suggested a fix off the top of my head. On Wed, Sep 19, 2018 at 2:57 PM Paul Eggert wrote: > Jeff Epler wrote: > > Changing to lchmodat should resolve the problem > > No, that would just introduce the opposite bug: chmod is suppo

bug#32772: TOCTOU bug in chmod

Jeff Epler wrote: Changing to lchmodat should resolve the problem No, that would just introduce the opposite bug: chmod is supposed to follow a symlink, and using lchmod would let an attacker provoke a race that would cause chmod to not follow a symlink that it should. A better way to fix

bug#32772: TOCTOU bug in chmod

When a directory is replaced with a symlink at a critical moment, `chmod` will perform the unintended action of changing the mode of the linked-to file or directory. I tested in coreutils 8.26 on debian stretch, but believe that the current version 8.30 and the development version are vulnerable

bug#31912: Question for David MacKenzie - why an mkdir has no silent mode (-f key) like a chmod?

On 06/20/2018 04:18 AM, bgv@gmail.com wrote: A simple question for David MacKenzie - why an mkdir has no silent mode (-f key) like a chmod? David MacKenzie left the building long ago. It sounds like you're looking for 'mkdir -p'. If not, you can just ignore mkdir's exit status

bug#31912: Question for David MacKenzie - why an mkdir has no silent mode (-f key) like a chmod?

tag 31912 notabug thanks On 06/20/2018 06:18 AM, bgv@gmail.com wrote: Hi, A simple question for David MacKenzie - why an mkdir has no silent mode (-f key) like a chmod? I'm not David (and it's been a while since he's posted anything to this list anyway), but thanks to the wonders

bug#31912: Question for David MacKenzie - why an mkdir has no silent mode (-f key) like a chmod?

Hi, A simple question for David MacKenzie - why an mkdir has no silent mode (-f key) like a chmod? Bye. Gennady Baranov, Technical director, Senior engineer IOIX UA http://ioix.com.ua/ Head of HCE project

bug#30477: [PATCH] chmod chown chgrp: added --exclude-files and --exclude-directories

ed. > > Such functionality has been discussed previously at: > https://www.gnu.org/software/coreutils/rejected_requests.html#chmod > > thanks, > Pádraig

bug#30477: [PATCH] chmod chown chgrp: added --exclude-files and --exclude-directories

ly target files > or directories. > Tests of correctness also included. > > Any input or feedback greatly appreciated. Such functionality has been discussed previously at: https://www.gnu.org/software/coreutils/rejected_requests.html#chmod thanks, Pádraig

bug#30477: [PATCH] chmod chown chgrp: added --exclude-files and --exclude-directories

, and this is frightening. In most cases I would surmise that the user simply needed -R —exclude-files +rx And in none of these cases do the users understand find or xargs or |, etc. beyond their understanding of copy/paste. I do believe that usability was a goal of {chown, chmod, chgrp} because

bug#30477: [PATCH] chmod chown chgrp: added --exclude-files and --exclude-directories

e example/scenario where this is needed, and find/xargs are not sufficient ? For example, to apply chmod/chown/chgrp on files alone (like your --exclude-directories), one can use: find $DIR -type f | xargs chmod [NEWMODE] And of course, find's predicates can be expanded to include symlinks, sockets

bug#30477: [PATCH] chmod chown chgrp: added --exclude-files and --exclude-directories

Hello all, Apologies if I have incorrectly followed any conventions. I’ve tried. Attached please find a new feature I created to simplify setting permissions (especially recursively), which enables the user to separately target files or directories. Tests of correctness also included. Any

bug#29207: info chmod

On 12/16/2017 11:10 PM, Bernhard Voelker wrote: The attached patch [...] push with a slightly improved commit message at https://git.sv.gnu.org/cgit/coreutils.git/commit/?id=47fb363432 Marking this as done. Have a nice day, Berny

bug#29207: info chmod

<m...@bernhard-voelker.de> Date: Sat, 16 Dec 2017 23:07:27 +0100 Subject: [PATCH] doc: mention which privileges are needed to chmod [1] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/chmod.html * doc/coreutils.texi (chmod invocation): Document who can change the file mode bits

bug#29390: chmod man page - clear setuid/setgid with numerical value

On 21/11/17 18:46, Oliver Isaac wrote: > Hello, > > There is an incorrect assertion made in the chmod man page: > > Under the setuid/setgid header it says, "you can set (but not clear) the bits > with a numeric mode" > > This is not entirely true. If you

bug#29390: chmod man page - clear setuid/setgid with numerical value

Hello, There is an incorrect assertion made in the chmod man page: Under the setuid/setgid header it says, "you can set (but not clear) the bits with a numeric mode" This is not entirely true. If you prefix your numeric mode with a 0 then it will work: e.g.: touch myfile chmod 644

bug#29207: info chmod

On 09.11.2017 11:53, Bernhard Voelker wrote: On 11/08/2017 11:54 AM, kalle wrote: info chmod doesn't say, which users can apply it successfully. The same for info chown. Well, it does - indirectly: https://www.gnu.org/software/coreutils/manual/html_node/chmod-invocation.html#chmod

bug#29207: info chmod

On 11/08/2017 11:54 AM, kalle wrote: > info chmod doesn't say, which users can apply it successfully. The same > for info chown. Well, it does - indirectly: https://www.gnu.org/software/coreutils/manual/html_node/chmod-invocation.html#chmod-invocation [...] This behavior d

bug#29207: info chmod

info chmod doesn't say, which users can apply it successfully. The same for info chown. Are the related man-pages also maintained by GNU coreutils? They also have the same deficiencies... greetings, kalle

bug#28912: chmod (2) – Issues report

On 10/20/2017 01:07 PM, Eric Blake wrote: > As such, I'm closing this as not a bug. However, feel free to add > further comments to this thread if you have further evidence for > coreutils not doing something required/permitted by POSIX, or not doing > something that matches what is already

bug#28912: chmod (2) – Issues report

utils parses symbolic mode strings: https://www.gnu.org/software/coreutils/manual/coreutils.html#Setting-Permissions Every chmod mode string is divided into three parts: USERS (the leading [ugoa]...), OPERATIONS (the [-+=]), and the PERMISSIONS (either zero or more from [rwxXst] or a single lett

bug#28914: chmod (2) – Issues report

Current issue was also reported as Bug 1504053 and closed by someone not at the right place as notabug.

bug#28912: chmod (2) – Issues report

>From the followings inputs it should be expected to produce regarding the input format either error or a warning messages. As empty sets all the input tests have been conducted. Format of input that were validated with no kind of message from coreutils: # chmod [ugoa][+-=][rwxXst] [u

bug#25495: WTF? Chmod (and presumably other coreutils) corrupt their own error messages with "smart" quotes...

Alain Knaff wrote: $ LC_ALL=C.UTF-8 chmod 0 chmod: cannot access ‘’: No such file or directory It looks like you're using an old version of coreutils. The current version outputs ASCII apostrophes there. This was a change committed on 2015-11-04 and released in coreutils 8.25

bug#25495: WTF? Chmod (and presumably other coreutils) corrupt their own error messages with "smart" quotes...

On 01/20/2017 23:33, Eric Blake wrote: > On 01/20/2017 03:44 PM, Alain Knaff wrote: >> Hi, >> >> Recently, while browsing error mails of some cron jobs, I noticed that >> chmod puts "smart" quotes into its error messages. >> >> IMHO, suc

bug#25495: WTF? Chmod (and presumably other coreutils) corrupt their own error messages with "smart" quotes...

On 01/20/2017 03:44 PM, Alain Knaff wrote: > Hi, > > Recently, while browsing error mails of some cron jobs, I noticed that > chmod puts "smart" quotes into its error messages. > > IMHO, such gimmicks should have no place in core utilities. > > At least th

bug#25495: WTF? Chmod (and presumably other coreutils) corrupt their own error messages with "smart" quotes...

Hi, Recently, while browsing error mails of some cron jobs, I noticed that chmod puts "smart" quotes into its error messages. IMHO, such gimmicks should have no place in core utilities. At least this behavior should be optional via configuration or environment setting (preferably off

bug#25223: chmod +w does not work

Eugen Dedu wrote: Is there a rationale for this, i.e. chmod to use umask? It's specified by POSIX. I expect the idea was to make it a bit harder to grant permissions that the user didn't intend.

bug#25223: chmod +w does not work

On 18/12/16 18:34, Pádraig Brady wrote: tag 25223 notabug close 25223 stop On 18/12/16 12:37, Eugen Dedu wrote: Hi, chmod +w file does not work: snoopy:~$ touch ff snoopy:~$ ls -l ff -rw-r--r-- 1 ededu ededu 0 Dec 18 13:31 ff snoopy:~$ chmod +w ff snoopy:~$ ls -l ff -rw-r--r-- 1 ededu ededu

bug#25223: chmod +w does not work

tag 25223 notabug close 25223 stop On 18/12/16 12:37, Eugen Dedu wrote: > Hi, > > chmod +w file does not work: > > snoopy:~$ touch ff > snoopy:~$ ls -l ff > -rw-r--r-- 1 ededu ededu 0 Dec 18 13:31 ff > snoopy:~$ chmod +w ff > snoopy:~$ ls -l ff > -rw-r--r-- 1

bug#25223: chmod +w does not work

Hi, chmod +w file does not work: snoopy:~$ touch ff snoopy:~$ ls -l ff -rw-r--r-- 1 ededu ededu 0 Dec 18 13:31 ff snoopy:~$ chmod +w ff snoopy:~$ ls -l ff -rw-r--r-- 1 ededu ededu 0 Dec 18 13:31 ff snoopy:~$ chmod +x ff snoopy:~$ ls -l ff -rwxr-xr-x 1 ededu ededu 0 Dec 18 13:31 ff snoopy

bug#23853: chmod can unset sticky bits using octet format

On 06/26/2016 06:56 PM, westlake wrote: > According to chmod's manpage, > "chmod preserves a directory's set-user-ID and set-group-ID bits unless > you explicitly specify otherwise. You can set or clear the bits with > symbolic modes like u+s and g-s, and you can set (but not

bug#23853: chmod can unset sticky bits using octet format

According to chmod's manpage, "chmod preserves a directory's set-user-ID and set-group-ID bits unless you explicitly specify otherwise. You can set or clear the bits with symbolic modes like u+s and g-s, and you can set (but not clear) the bits with a numeric mode."

bug#23353: i am gettin problem in reload, it giving chmod error as given

tags 23353 notabug close 23353 thanks On 04/24/2016 08:29 AM, Akshaj Vk wrote: > levin@ubuntu-1gb-sgp1-01:~$ sudo apt-get remove apache2* > > E: Could not open lock file /var/lib/dpkg/lock - open (2: No such file or > directory) > > E: Unable to lock the administration directory

bug#23353: i am gettin problem in reload, it giving chmod error as given

levin@ubuntu-1gb-sgp1-01:~$ sudo apt-get remove apache2* E: Could not open lock file /var/lib/dpkg/lock - open (2: No such file or directory) E: Unable to lock the administration directory (/var/lib/dpkg/), are you root? levin@ubuntu-1gb-sgp1-01:~$ sudo /etc/init.d/apache2 reload * Reloading

bug#20143: --dry-run for chmod and chown

Hi folks, a dry run mode for chmod and chown would be very helpful, especially together with -v --reference-file. Hopefully I am not too blind to see. Most recent version I checked was coreutils 8.23. Thanx very much. Please keep on your good work Harri -- aixigo AG, Karl-Friedrich-Strasse

bug#19447: chmod - problem

Hi chmod does not work recursively. The command chmod --recursive --verbose a-x ./*.txt only has effects in the actual working directory, but not in the subdirectories. Cheers, Tom

bug#19447: chmod - problem

tag 19447 notabug close 19447 stop On 26/12/14 18:28, Tom wrote: Hi chmod does not work recursively. The command chmod --recursive --verbose a-x ./*.txt only has effects in the actual working directory, but not in the subdirectories. You're passing only .txt files to chmod here so

bug#19447: chmod - problem

the problem in this bug ticket until it all makes sense. Others having the same confusion can read it and it will help them later. Tom wrote: chmod does not work recursively. The command chmod --recursive --verbose a-x ./*.txt only has effects in the actual working directory

bug#19377: bug#19378: [PATCH 3/4] cat, chcon, chgrp, chmod, chown, cp, du, head: support wildcards on OS/2

On Mon, Dec 15, 2014 at 9:11 PM, KO Myung-Hun kom...@gmail.com wrote: Jim Meyering wrote: On Mon, Dec 15, 2014 at 8:35 PM, KO Myung-Hun kom...@gmail.com wrote: Paul Eggert wrote: KO Myung-Hun wrote: /* Redirection and wildcarding when done by the utility itself. Generally a noop, but

bug#19375: closed (Re: bug#19377: bug#19378: [PATCH 3/4] cat, chcon, chgrp, chmod, chown, cp, du, head: support wildcards on OS/2)

/ginstall -man/vdir.1: src/vdir - -man/base64.1:src/base64 -man/basename.1: src/basename -man/cat.1: src/cat -man/chcon.1: src/chcon -man/chgrp.1: src/chgrp -man/chmod.1: src/chmod -man/chown.1: src/chown -man/chroot.1:src/chroot -man/cksum.1: src/cksum

bug#19375: closed (Re: bug#19377: bug#19378: [PATCH 3/4] cat, chcon, chgrp, chmod, chown, cp, du, head: support wildcards on OS/2)

reopen 19377 stop On 19/12/14 01:13, KO Myung-Hun wrote: GNU bug Tracking System wrote: Your bug report #19377: [PATCH 1/4] doc: add $(EXEEXT) suffix to the executables which was filed against the coreutils package, has been closed. The explanation is attached below, along with your

bug#19375: closed (Re: bug#19377: bug#19378: [PATCH 3/4] cat, chcon, chgrp, chmod, chown, cp, du, head: support wildcards on OS/2)

Pádraig Brady wrote: reopen 19377 stop On 19/12/14 01:13, KO Myung-Hun wrote: GNU bug Tracking System wrote: Your bug report #19377: [PATCH 1/4] doc: add $(EXEEXT) suffix to the executables which was filed against the coreutils package, has been closed. The explanation is attached

bug#19377: bug#19378: [PATCH 3/4] cat, chcon, chgrp, chmod, chown, cp, du, head: support wildcards on OS/2

On 15/12/14 01:15, KO Myung-Hun wrote: Pádraig Brady wrote: forcemerge 19378 19377 stop On 14/12/14 03:47, KO Myung-Hun wrote: And ln,ls,mv,rm,tail. * src/cat.c (main): Expand wildcards on OS/2. * src/chcon.c (main): Likewise. * src/chgrp.c (main): Likewise. * src/chmod.c (main):

bug#19377: bug#19378: [PATCH 3/4] cat, chcon, chgrp, chmod, chown, cp, du, head: support wildcards on OS/2

On Mon, Dec 15, 2014 at 12:57 AM, Pádraig Brady p...@draigbrady.com wrote: On 15/12/14 01:15, KO Myung-Hun wrote: Pádraig Brady wrote: forcemerge 19378 19377 stop On 14/12/14 03:47, KO Myung-Hun wrote: And ln,ls,mv,rm,tail. * src/cat.c (main): Expand wildcards on OS/2. * src/chcon.c

bug#19377: bug#19378: [PATCH 3/4] cat, chcon, chgrp, chmod, chown, cp, du, head: support wildcards on OS/2

Pádraig Brady wrote: On 15/12/14 01:15, KO Myung-Hun wrote: Pádraig Brady wrote: forcemerge 19378 19377 stop On 14/12/14 03:47, KO Myung-Hun wrote: And ln,ls,mv,rm,tail. * src/cat.c (main): Expand wildcards on OS/2. * src/chcon.c (main): Likewise. * src/chgrp.c (main): Likewise. *

bug#19377: bug#19378: [PATCH 3/4] cat, chcon, chgrp, chmod, chown, cp, du, head: support wildcards on OS/2

KO Myung-Hun wrote: /* Redirection and wildcarding when done by the utility itself. Generally a noop, but used in particular for native VMS. */ #ifndef initialize_main -# define initialize_main(ac, av) +# ifndef __OS2__ +# define initialize_main(ac, av) +# else What happened to VMS?

bug#19377: bug#19378: [PATCH 3/4] cat, chcon, chgrp, chmod, chown, cp, du, head: support wildcards on OS/2

Paul Eggert wrote: KO Myung-Hun wrote: /* Redirection and wildcarding when done by the utility itself. Generally a noop, but used in particular for native VMS. */ #ifndef initialize_main -# define initialize_main(ac, av) +# ifndef __OS2__ +# define initialize_main(ac, av) +#

bug#19377: bug#19378: [PATCH 3/4] cat, chcon, chgrp, chmod, chown, cp, du, head: support wildcards on OS/2

On Mon, Dec 15, 2014 at 8:35 PM, KO Myung-Hun kom...@gmail.com wrote: Paul Eggert wrote: KO Myung-Hun wrote: /* Redirection and wildcarding when done by the utility itself. Generally a noop, but used in particular for native VMS. */ #ifndef initialize_main -# define

bug#19377: bug#19378: [PATCH 3/4] cat, chcon, chgrp, chmod, chown, cp, du, head: support wildcards on OS/2

Jim Meyering wrote: On Mon, Dec 15, 2014 at 8:35 PM, KO Myung-Hun kom...@gmail.com wrote: Paul Eggert wrote: KO Myung-Hun wrote: /* Redirection and wildcarding when done by the utility itself. Generally a noop, but used in particular for native VMS. */ #ifndef initialize_main -#

bug#19377: bug#19378: [PATCH 3/4] cat, chcon, chgrp, chmod, chown, cp, du, head: support wildcards on OS/2

forcemerge 19378 19377 stop On 14/12/14 03:47, KO Myung-Hun wrote: And ln,ls,mv,rm,tail. * src/cat.c (main): Expand wildcards on OS/2. * src/chcon.c (main): Likewise. * src/chgrp.c (main): Likewise. * src/chmod.c (main): Likewise. * src/chown.c (main): Likewise. * src/cp.c (main):

bug#19377: bug#19378: [PATCH 3/4] cat, chcon, chgrp, chmod, chown, cp, du, head: support wildcards on OS/2

Pádraig Brady wrote: forcemerge 19378 19377 stop On 14/12/14 03:47, KO Myung-Hun wrote: And ln,ls,mv,rm,tail. * src/cat.c (main): Expand wildcards on OS/2. * src/chcon.c (main): Likewise. * src/chgrp.c (main): Likewise. * src/chmod.c (main): Likewise. * src/chown.c (main): Likewise.

bug#19378: [PATCH 3/4] cat, chcon, chgrp, chmod, chown, cp, du, head: support wildcards on OS/2

And ln,ls,mv,rm,tail. * src/cat.c (main): Expand wildcards on OS/2. * src/chcon.c (main): Likewise. * src/chgrp.c (main): Likewise. * src/chmod.c (main): Likewise. * src/chown.c (main): Likewise. * src/cp.c (main): Likewise. * src/du.c (main): Likewise. * src/head.c (main): Likewise. * src/ln.c

bug#18937: chmod ???? bug?

Le 04/11/2014 18:47, Bob Proulx a écrit : Plato wrote: After using chmod chmod -R 644 /media/plato/mountedpartition/ (I see I forgot the * at the end) That is a problematic command regardless of the '*' at the end or not. If any of the arguments is a directory then it will set

bug#18937: chmod ???? bug?

chmod -R u=rwX,g=rwX[s],o=[---|rX|rwX] /media/plato/mountedpartition/ (no need the *, implied by -R)

bug#18937: chmod ???? bug?

Plato wrote: After using chmod chmod -R 644 /media/plato/mountedpartition/ (I see I forgot the * at the end) That is a problematic command regardless of the '*' at the end or not. If any of the arguments is a directory then it will set the directory permission to 644 as specified

bug#18937: chmod ???? bug?

Hello, After using chmod chmod -R 644 /media/plato/mountedpartition/ (I see I forgot the * at the end) my ls -l listing has all entry's like these: First a list like this of every file and folder ls: cannot access /media/plato/mountedpartition

bug#18280: chmod: race condition

Tobias Stoeckmann wrote: For me, it sounds like configure should run a functionality test, calling fchmodat with AT_SYMLINK_NOFOLLOW and see if it fails and ENOTSUP is set in errno. In that case, don't call fchmodat or force 0 for flags, otherwise use AT_SYMLINK_NOFOLLOW. Yes, that sounds

bug#18280: chmod: race condition

Hi, chmod is vulnerable to a TOCTTOU (time of check to time of use) race condition. Tested this on an OpenBSD system. For people unfamiliar with OpenBSD, /etc/master.passwd basically equals /etc/shadow: # chmod --version | head -n 1 chmod (GNU coreutils) 8.23 # ls -l /etc/master.passwd -rw

bug#18280: chmod: race condition

Tobias Stoeckmann wrote: But I will recommend to look into the use of fchmodat() instead, supplying the argument AT_SYMLINK_NOFOLLOW. Sorry, that won't work, and this is a known bug. Please see: http://bugs.gnu.org/11108

bug#17907: Problem with 'chmod' (LinuxMint 64 v17 - KDE)

Hello I am french and I hope you will excuse my very bad english. I try to modify the permissions of a file, but I don't succeed. I want the file 'essai.sh' became executable : so I want to transform the permissions from '-rw---' to '-rwx--', usign 'chmod' (in 'root'). But... Look

bug#17907: Problem with 'chmod' (LinuxMint 64 v17 - KDE)

from '-rw---' to '-rwx--', usign 'chmod' (in 'root'). But... Look, please : yves@yves:/media/yves/Partition-ntfs/Travaux/DOCUS/Informatique/Scripts ^^ NTFS is a notoriously difficult file system (not as bad as FAT, but still not POSIX compliant

bug#17035: [PATCH] chmod -c -R produces errors with special permissions

saw the same warning from chmod -R -c when playing with recursive bind-mounts, i.e., there were no files or directories with special bits set. Interesting. Looking at the code seems that message is restricted to the above condition where those bits are set. Can you reproduce? Yes, fortunately

bug#17035: [PATCH] chmod -c -R produces errors with special permissions

chmod sometimes tries to stat files in the wrong directory when reporting changes: mkdir -p a/b chmod -R g+s a/b # requires some special permission bit set first chmod -c -R g+w a chmod: getting new attributes of 'b': No such file or directory A fix is attached. From

bug#17035: [PATCH] chmod -c -R produces errors with special permissions

On 03/18/2014 04:06 PM, Dylan Alex Simon wrote: chmod sometimes tries to stat files in the wrong directory when reporting changes: mkdir -p a/b chmod -R g+s a/b # requires some special permission bit set first chmod -c -R g+w a chmod: getting new attributes of 'b': No such file

bug#17035: [PATCH] chmod -c -R produces errors with special permissions

/NEWS index 35d48e5..3623674 100644 --- a/NEWS +++ b/NEWS @@ -4,6 +4,9 @@ GNU coreutils NEWS-*- outline -*- ** Bug fixes + chmod -R --changes no longer issues erroneous warnings for files with special + bits set. [bug introduced in coreutils-5.1.0

bug#17035: [PATCH] chmod -c -R produces errors with special permissions

On 03/18/2014 07:45 PM, Pádraig Brady wrote: @@ -121,7 +121,7 @@ mode_changed (int dirfd, char const *file, char const *file_full_name, struct stat new_stats; - if (fstatat (dirfd, file, new_stats, 0) != 0) + if (fstatat (dir_fd, file, new_stats, 0) != 0) {

bug#17035: [PATCH] chmod -c -R produces errors with special permissions

On Tue, Mar 18, 2014 at 11:45 AM, Pádraig Brady p...@draigbrady.com wrote: diff --git a/tests/chmod/c-option.sh b/tests/chmod/c-option.sh ... +# This should never warn, but in did when special +# bits are set on b (the common case under test) +chmod -c -R g+w a 2err +test -s err fail=1

  1   2   3   4   5   >