Find the answer to your Linux question:
Page 1 of 2 1 2 LastLast
Results 1 to 10 of 11
Hi all... been a HPUX admin for 6+ years, but not as well up on Linux as I'd like to be... OS is a Red Hat derived Linux. Quick scenario... ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Jul 2006
    Location
    Cork, Ireland
    Posts
    6

    vi overwriting read-only file??


    Hi all...

    been a HPUX admin for 6+ years, but not as well up on Linux as I'd like to be...

    OS is a Red Hat derived Linux.

    Quick scenario... I have a directory, say /tmp/mydir, permissions 777 (sticky bit NOT set), owner is root. In that directory I have a file called myfile, permissions 744, owner is root. User 'bob' comes along, and does vi /tmp/mydir/myfile. He gets a warning that he is editing a read-only file.

    All cool so far. However, now 'bob' makes a change to the file, and does :w!. Vi actually does the overwriting, and now instead of the file being owned by root it is owned by bob, with the changes bob made saved! :o

    Am I going nuts here or should that just not work?? All I can guess is that the file was deleted and recreated, but that shouldn't have happened.

    Any ideas on whats going on here? or is this something you can do in Red Hat linux?

    Kev.

  2. #2
    Just Joined!
    Join Date
    Jul 2006
    Location
    Cork, Ireland
    Posts
    6
    Oh ya, forgot to mention, the user bob isn't an equivalent root user, just a 'normal' joe soap user with no special permissions.

  3. #3
    Linux Enthusiast
    Join Date
    Aug 2005
    Location
    Hell
    Posts
    514
    Quote Originally Posted by kevinod
    Hi all...

    been a HPUX admin for 6+ years, but not as well up on Linux as I'd like to be...

    OS is a Red Hat derived Linux.

    Quick scenario... I have a directory, say /tmp/mydir, permissions 777 (sticky bit NOT set), owner is root. In that directory I have a file called myfile, permissions 744, owner is root. User 'bob' comes along, and does vi /tmp/mydir/myfile. He gets a warning that he is editing a read-only file.

    All cool so far. However, now 'bob' makes a change to the file, and does :w!. Vi actually does the overwriting, and now instead of the file being owned by root it is owned by bob, with the changes bob made saved! :o

    Am I going nuts here or should that just not work?? All I can guess is that the file was deleted and recreated, but that shouldn't have happened.

    Any ideas on whats going on here? or is this something you can do in Red Hat linux?

    Kev.
    This is perfectly normal. You don't understand permissions. The permission to create or delete files is the write permission of the parent directory.

  4. #4
    Just Joined!
    Join Date
    Jul 2006
    Location
    Cork, Ireland
    Posts
    6
    Quote Originally Posted by spoon!
    This is perfectly normal. You don't understand permissions. The permission to create or delete files is the write permission of the parent directory.
    I understand creating or deleting files is to do with the parent directory, but this is EDITING the file.

    The user was editing the file, and was allowed to overwrite a file he/she did not have write access to. Surely that can't be right??

  5. #5
    Just Joined!
    Join Date
    Jul 2006
    Location
    Cork, Ireland
    Posts
    6
    Just to rephrase that slightly... the user was allowed to force save a file he/she did not have write access to.

  6. #6
    Linux Engineer rcgreen's Avatar
    Join Date
    May 2006
    Location
    the hills
    Posts
    1,134
    There's no way that should happen. Either something is broken
    or you are mistaken about what permissions are really on the file.
    It may be owned by root, but with write permission for other users.

    Do a ls -l <file> and double check that it is read only.
    Maybe vi saved an edited file, but left the original unchanged.

    There's nothing to stop a user from copying and editing his
    copy, but he shouldn't be able to edit the original. It would
    be the end of civilization as we know it.


    Well, maybe I spoke too soon. Since the directory is 777,
    you will have to set the sticky bit to prevent this behavior.
    Wierd, but true.

  7. #7
    Linux Enthusiast
    Join Date
    Aug 2005
    Location
    Hell
    Posts
    514
    Quote Originally Posted by kevinod
    I understand creating or deleting files is to do with the parent directory, but this is EDITING the file.

    The user was editing the file, and was allowed to overwrite a file he/she did not have write access to. Surely that can't be right??
    So I assume what happened is the file was deleted and a new file was created.

  8. #8
    Just Joined!
    Join Date
    Jul 2006
    Location
    Cork, Ireland
    Posts
    6
    I checked this last night on a HPUX 11.00 workstation and a Sun Solaris 8 workstation, and neither allowed the force write, both said "permission denied".

    It does allow it on Red Hat 4 though... I guess its whatever way the Linux version of the vi/vim editor implements the force write, a bit different to the commercial unixes.

    One I'll have to watch out for!

    cheers,
    Kev.

  9. #9
    Linux Guru Cabhan's Avatar
    Join Date
    Jan 2005
    Location
    Seattle, WA, USA
    Posts
    3,252
    I found something in the Vim documentation:
    Code:
    							*write-readonly*
    When the 'cpoptions' option contains 'W', Vim will refuse to overwrite a
    readonly file.  When 'W' is not present, ":w!" will overwrite a readonly file,
    if the system allows it (the directory must be writable).
    Now then, this essentially allows you to set certain compatibility with vi: the vi default acts as though all flags are set (vi doesn't actually have this option), while Vim has 'aABceFs' set by default.

    You can change this, as you probably know, just by editing the vimrc.

    So what I would suppose happened is that you are running different compatibilities with each system. Because the ability to delete and create a file is specified by the directory's write permission (and /tmp is 777), you were allowed to do this because 'W' was not set.

  10. #10
    Just Joined!
    Join Date
    Jul 2006
    Location
    Cork, Ireland
    Posts
    6
    That sounds like whats happening alright, great stuff! I'll try it out just to be sure to be sure but I reckon that should solve the mystery.

    thanks!

Page 1 of 2 1 2 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •