Re: Security question regarding directory and file permissions

From: Sebastian Hans (hanss_at_in.tum.de)
Date: 06/05/03


Date: Thu, 5 Jun 2003 14:48:11 +0000 (UTC)

Mhoram <mwathke@netscape.net> wrote:
> I am wondering if the following scenario (which I can produce on
> RedHat 8 and RedHat 9 systems, but not on AIX or Solaris) is a bug or
> is done by design.
>
> I create a directory called /test with permissions of 777. Then, as
> user1, I create a file called testfile in that directory. The file
> has permissions of 664, owner is user1, and group is user1. I then
> log in as user2, change to the test directory, and edit the file using
> vi. Vi correctly states that the file is being opened read-only.
> While still in vi, I add a line to the file and try to save it using
>:w to which vi again states that the file is read-only. So far so
> good. But if I save my changes using :w! - vi allows the change.
> When I exit vi and do an ls, the file still has permissions of 664,
> but is now owned by user2 with a group of user2.
>
> Is this how it should work? I thought that file permissions would
> override the directory permissions in the above example when trying to
> write to the file. And even if the file changes should be allowed to
> be written, I was certainly surprised to see the owner and group
> change.

I just tried this with vim 6.1 and it works just like you described.

A wild guess: Since you are forcing the write with '!' and vi notices
that you can't write to the file but you can write to the directory, it
deletes the original file and creates a new one, which is then, of
course, owned by user2.

So the important point is: don't put a file that you don't want to have
changed in a publicly writable directory, because another user doesn't
have to actually *change* the file. He/she only has to change the
directory, i.e. replace the file with another one.

The reason that this can not be reproduced on another system is that
RedHat probably has vim and AIX and Solaris have some other vi.

And, yes, this is how file/directory permissions should work.
Wether it is how vim should work is another matter entirely. The reason
this is done is probably that it is assumed that you know what you are
doing when you go around forcing things.

HTH

Seb.



Relevant Pages

  • Re: Security question regarding directory and file permissions
    ... I thought that file permissions would ... > I just tried this with vim 6.1 and it works just like you described. ... > The reason that this can not be reproduced on another system is that ... > doing when you go around forcing things. ...
    (comp.os.linux.security)
  • Re: ACBL GCC -- 1M[STR NAT]-(P)-1NT[FG]
    ... I'm looking for clarification about various permissions granted under ... ONE NOTRUMP response to a major suit opening bid forcing one round; ... CONVENTIONAL RESPONSES WHICH GUARANTEE GAME ... FORCING OR BETTER VALUES. ...
    (rec.games.bridge)
  • Re: Permissions
    ... Changing the permissions on a file doesn't seem to help, ... WINDOWS DOING STUFF THAT I DIDN'T ASK FOR. ... I don't want anything automatically updating. ... There is no reason for media player to run at all. ...
    (microsoft.public.windows.vista.security)
  • Re: Permissions
    ... I couldn't delete a bunch of stuff in "documents and settings". ... Changing the permissions on a file doesn't seem to help, ... I don't want anything automatically updating. ... There is no reason for media player to run at all. ...
    (microsoft.public.windows.vista.security)
  • Re: Permissions
    ... Changing the permissions on a file doesn't seem to help, ... WINDOWS DOING STUFF THAT I DIDN'T ASK FOR. ... I don't want anything automatically updating. ... There is no reason for media player to run at all. ...
    (microsoft.public.windows.vista.security)