bug-sed
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#27200: sed happily modifies read-only files.


From: Bob Proulx
Subject: bug#27200: sed happily modifies read-only files.
Date: Tue, 6 Jun 2017 15:42:59 -0600
User-agent: NeoMutt/20170306 (1.8.0)

Péter wrote:
> I find it "interesting" that you do not see this as an erroneous behaviour.

What you are seeing as erroneous behavior is the Unix file system
permissions model.  You may not like it.  But that is the way it
works.  And it has been this way for decades.

Note that there have been other permission models that work
differently.  Such as those that use access control lists and other
models.  I remember AFS as having been much more intuitive for
non-unix users.  But again, those are different from the Unix file
system permission model.

> That permission bit means that "do not overwrite [nor delete] it,
> ask the user first".

That is incorrect.  That bit prevents writing to the file.  It has no
other indication.  (It is also not enforceable for the root user.)

If you want to prevent the file from being renamed then you must
remove write access to the directory containing the file.

If you want to really prevent all modifications then on a file system
by file system basis you can set extended attributes such as the EXT
file system's immutable flag.

  sudo chattr +i file1

> Its purpose is to give (some degree of) protection.
> Every text editor, the mv command, rm command, all ask confirmation from the
> user (or simply refuses to overwriting or even modifying).

This discussion is an excellent example of why I have always disliked
that rm and vi traditionally have added extra code to interact with
the user when the file is not writable by the user.  Because exactly
as it has done here it has taught mistaken things to users!  Very few
commands do anything special with read-only files.

> The "-f" switch which mv has, means "(this time I the user grants you:) do 
> not ask, assume yes for the confirmation".
> (And the "-n" switch means "do not ask, assume no for the confirmation".)
> 
> Only sed is which do not ask the user..

Not true.  And perl.  And python.  And ruby.  And the list goes on...
Pretty much every command other than vi, rm, mv.  It is easier to make
a list of commands that do special things than a list of commands
which do nothing special.

> I gave no "--force" switch to sed, and yet sed assumes as if that were given.
> Counterintuitive. Breaks the rules.

The rules are actually different than you think they are.  The rules
are that if you don't want the file to be renamed then you need to
remove write access from the directory containing it.  Or if you are
using a file system that supports it then you can use file system
specific methods such as immutable flags.

For example without any sed being involved at all:

  echo foo > file1
  chmod a-w file1
  perl -i -pe s/foo/bar/ file1

Or without using -i at all:

  echo foo > file1
  chmod a-w file1
  perl -pe s/foo/bar/ file1 > file2
  perl -e 'rename "file1", "file1.bak"'
  perl -e 'rename "file2", "file1"'
  chmod --reference file1.bak file1
  perl -e 'unlink "file1.bak"'

If you want to prevent the file from being renamed then it is needed
to make the directory holding it read-only.

  echo foo > file1
  chmod a-w file1
  chmod a-w .
  perl -pe s/foo/bar/ file1 > file2
    bash: file2: Permission denied
  perl -e 'rename "file1", "file1.bak" or die "cannot rename\n"'
    cannot rename
  perl -e 'rename "file2", "file1" or die "cannot rename\n"'
    cannot rename
  chmod --reference file1.bak file1
  perl -e 'unlink "file1.bak" or die "cannot unlink\n"'
    cannot unlink

Bob





reply via email to

[Prev in Thread] Current Thread [Next in Thread]