Subject: RE: [netatalk-admins] Newbie with a few questions..

From: Danny Carroll <[email-masked]>
Date: Thu, 26 Feb 1998 08:05:54 +1000

On Wednesday, 25 February 1998 20:08, Vivek [SMTP:[email-masked]] wrote:
> On Wed, 25 Feb 1998, Danny Carroll wrote:
>
> > I tried creating one for them (empty) and chown.chmodding it but I found
> > that
> > even though root owned the file..  You could rename it from the Mac...   -
> > BAD
> >
> > I wonder if you can do this to other files say /etc/passwd??
>
> The ability to move/delete a file depends on the directory permissions:
> You aren't altering the file itself, but the directory it is in. After
> all, if it's your directory, you get a say as to what lives there and what
> doesn't. It might take a bit of getting used to initially, but it all
> starts to make sense if you think about it for a while. Think of it like
> this - you aren't moving/deleting the file: you're removing/changing an
> entry that points to that file from the directory.

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

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

testuser logs in via apple...  Rename the file   (Have to click a few times)
 and hey presto, it looks like this..

1 drwxr-xr-x   3 testuser users        1024 Feb 26 08:05 ./
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 anynameyouwant

Testuser then can create a new AppleVolumes file.

how do you disable the use of AppleVolumes in home dir's??

-Danny

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Danny Carroll - CSO Academy of the Arts, QUT
Phone               (07) 3864-5903
Fax                   (07) 3864-5569
Mobile               0412-217-441
E-mail                [email-masked]

---

From: Andras Kadinger <[email-masked]>
Date: Wed, 25 Feb 1998 23:56:26 +0100

> how do you disable the use of AppleVolumes in home dir's??

If You really want to disable all AppleVolumes in home dirs, try the
patch below. It removes the check for the users's AppleVolumes files, so
effectively afpd then ignores them.

Be careful, I am not a very experienced patcher.

Sincerely,
Andras Kadinger
[email-masked]

---

From: Mark Donnelly <[email-masked]>
Date: Wed, 25 Feb 1998 17:10:18 -0600

>But it shouldn't be like that...  if I have a home diectory like this..

Well, what he's saying is that the system he described is just what UN*X does.
If you were to log in and try that using tcsh, bash, zsh, sh, etc, you would
have the same results.

If you're a programmer, think of this:  You have some data that you can't touch.
The only way to access the data is through a system call.  (Think of
filehandles...they're just integers, but the system deals with them)  Now, you
create an array of a structure that holds the reference to the data (say, the
filehandle), and an internal name for what that data is.  You could change that
name all day long if you wanted to, without touching the data.

Now, if you understand that, substitue 'data' to be 'file', and substitue
'structure' to be 'inode'.  The user owns the inodes (the directory structure),
and can change them at will -- they own the inodes -- but cannot touch the data
contained within the files.

Basically, the filename is not intrinsic to the data that is contained within.
The filename is part of the directory structure, which the user owns and can
change.

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

The users cannot alter the file....they altered the inodes that reference the
file.

If you want to _absolutely_ make sure that the user's AppleVolumes are not
scanned, get the source and change one line:

volume.c, line 118 (do a search in it for "AppleVolume")

The line

   } else if (( pwent = getpwnam( username )) != NULL ) { 

Can become

   } else if ( NULL ) { 

Now, two caveats:  1.  I'm based off the asun patches (just downloaded the
source from him), so this might be different in the base tree.

2.  I didn't test this, I just looked.  This LOOKS right, but you might have to
change a couple of things.

--Mark
   "I think so Brain, but if they called them sad meals, then 
    no one would buy them."

---

From: Bill Studenmund <[email-masked]>
Date: Wed, 25 Feb 1998 15:54:21 -0800 (PST)

> 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

> 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 

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