[prev in list] [next in list] [prev in thread] [next in thread] 

List:       netatalk
Subject:    RE: [netatalk-admins] Newbie with a few questions..
From:       Bill Studenmund <skippy () macro ! stanford ! edu>
Date:       1998-02-25 23:54:21
[Download RAW message or body]

On Thu, 26 Feb 1998, Danny Carroll wrote:

> On Wednesday, 25 February 1998 20:08, Vivek [SMTP:vivek@imaginet.co.uk] wrote:
> > On Wed, 25 Feb 1998, Danny Carroll wrote:
> >
> But it shouldn't be like that...  if I have a home diectory like this..
> user : testuser
> 
> 1 drwxr-xr-x   3 testuser users        1024 Feb 26 08:05 ./
      ^  ^  ^
      |  |  +--- Folks not "testuser" and not in the "users" group can't
      |  |       change file names
      |  |
      |  +------ Members of the "users" group can't change file names
      |
      +--------- user testuser CAN change the names of files in this
                 directory

> 1 drwxr-xr-x  11 root     root         1024 Feb 25 14:41 ../
> 1 -rw-r--r--   1 testuser users         251 Feb 22 01:14 .bash_history
> 1 -rw-r--r--   1 testuser users          24 Jul 14  1994 .bash_logout
> 1 -rw-r--r--   1 testuser users         220 Aug 24  1995 .bash_profile
> 1 -rw-r--r--   1 testuser users         124 Aug 24  1995 .bashrc
> 0 -rw-------   1 root     root            0 Feb 26 08:05 AppleVolumes

testuser can't change the AppleVolumes file's contents though.

> Then nothing should let testuser alter that file  EVEN if it is in the home 
> dir...

But the file's name is seperate from the file's contents, and as such
testuser can change the name.

Name entries in directory listings are just pointers to files. Since they
are themselves in a file, if you can write to the file containing
them (the file containing the directory in which they reside), you change
the name of a pointer (the visable name of a file).

One reason for this separation is that you can then have multiple names
pointing to one file. For instance, your ls above indicates that there are
three references to ./ . I'm going to assume this directory's path is
/home/testuser/. This in /home, there is a reference, named "testuser", to
the file representing this directory. In this directory itself, there is a
reference, named "." also refering to this directory. Thus when you cd . 
you come back to where you started. Unless your fs is broken, you also
have a directory in this directory. I'll call it subdir. In subdir, there
is a reference, named "..", which also points to the first directory. 

So  "/home/testuser", "/home/testuser/.", and "/home/testuser/subdir/.."
all point to the same file (which is the special type called a directory
and contains all the above stuff).

So, annoying as it is, what you've seen is perfectly legit. UN*X behavior.
Just to see that permissions are ok, you weren't able to change the
contents of the AppleVolumes file, were you?

I hope this explanation helped.

Take care,

Bill

[prev in list] [next in list] [prev in thread] [next in thread]