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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 41554 in the body.
You can then email your comments to 41554 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Will Rosecrans <wrosecrans <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: chmod allows removing x bit on chmod without a force flag, which can
 be inconvenient to recover from
Date: Tue, 26 May 2020 18:30:14 -0700

[Message part 1 (text/plain, inline)]

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 by accident because of a bug, and it would make the system
inconvenient to recover.  Since it's almost never a desirable operation,
chmodding chmod itself could simply fail unless something like --force is
supplied.  The underlying safety logic is similar to that behind the
existing "--(no-)preserve-root"

[Message part 2 (text/html, inline)]

Message #8 received at 41554 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Will Rosecrans <wrosecrans <at> gmail.com>, 41554 <at> debbugs.gnu.org
Subject: Re: bug#41554: chmod allows removing x bit on chmod without a force
 flag, which can be inconvenient to recover from
Date: Tue, 26 May 2020 19:54:07 -0700

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 "/".

Message #11 received at 41554 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Will Rosecrans <wrosecrans <at> gmail.com>
Cc: 41554 <at> debbugs.gnu.org
Subject: Re: bug#41554: chmod allows removing x bit on chmod without a force
 flag, which can be inconvenient to recover from
Date: Wed, 27 May 2020 10:13:12 +0200

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
> inconvenient to recover.

It will likely fail with EPERM.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Message #14 received at 41554 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: Will Rosecrans <wrosecrans <at> gmail.com>
Cc: 41554 <at> debbugs.gnu.org
Subject: Re: bug#41554: chmod allows removing x bit on chmod without a force
 flag, which can be inconvenient to recover from
Date: Fri, 29 May 2020 17:01:50 -0600

tag 41554 + notabug
close 41554
thanks

Will Rosecrans wrote:
> Based on an inane interview question that was discussed here on Twitter:
> https://twitter.com/QuinnyPig/status/1265286980859908102

It's an interview question.  The purpose of this type of question is
never a practical existing problem but is instead to create a unique,
unusual, and unlikely to have been previously experienced problem for
discussion with the candidate.  To see how the candidate thinks about
problems like this.  To see if they give up immediately or if they
persevere on.  To see if they try to use available resources such as
discussing the problem with the interviewer.  It's a method to see the
candidate's problem solving skills in action.  If the candidate says,
here is the canonical correct solution, then the interviewer knows
that the candidate has seen this question before, the interviewer will
have learned nothing about the candidates problem solving skills, and
will simply move on to another question continuing to try to assess this.

I am not particularly fond of interviewers that fish for a particular
answer.  Better when the interviewer knows they are looking for an
open ended discussion.  The goal is assessing the candidate's problem
solving ability not rote memorization of test prep questions and
answers.

It is easy to say, oh, we will simply have the program avoid changing
itself, since it that would almost never desirable.  But that says
that it is sometimes desirable.  And though easy to say it is actually
very hard to program it to avoid creating new bugs.  I might say
impossible.

If this particular case were to be modified in the program the only
results would be that the interviewer would need to look for a
different inane, unique, unusual, and unlikely to have been
experienced situation to put the candidate in.  But along the way the
program would have acquired a bit of cruft.  It would be an unnatural
growth on the program source.  It would forever need testing.  It adds
complexity.  It would likely be the source of an actual real world
bug.  As opposed 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 recover.  Since it's almost never a desirable operation,
> chmodding chmod itself could simply fail unless something like --force is
> supplied.  The underlying safety logic is similar to that behind the
> existing "--(no-)preserve-root"

There are an infinite number of ways for someone to program a
mistake.  Trying to enumerate them all in a program to prevent them is
one of them.

Bob

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.