Subject: [netatalk-admins] special bits and such

From: a sun <[email-masked]>
Date: Fri, 7 Nov 1997 13:07:17 -0800 (PST)

in case people are interested, my next patch (a18) will have
modifications to allow retention of special permission bits. here's
what i did:
	1) altered DEFMASK in ad_open.c to 7700.
	2) added a change_perm (given at end) to unix.c.
	3) replaced all but one of the chmod's with change_perm's (one
	   of the chmod's actually has stat information already, so i
	   just used that).
	4) presto! setgid bits now stay and propagate.

#ifndef __GNUC__
#define __inline__
#endif

static __inline__ int change_perm(const char *path, mode_t mode)
{
  struct stat st;

  if (stat(path, &st) < 0) {
    return -1;
  }
  return chmod(path, (st.st_mode & 07000) | mode);
}

---

From: Jeff Wiegley <[email-masked]>
Date: Fri, 07 Nov 1997 15:41:23 -0800

>   return chmod(path, (st.st_mode & 07000) | mode);

Thanks for all the great help guys.  I am still trying to do the patch
myself,
if for no other reason than to learn the workings of netatalk better and
to get
a quick and dirty solution working.

One other caveat I know is that calls to chown also have the ability to
strip the suid, sgid and sticky bit (under linux at least).  I'm not
sure
off the top of my head if this behavior should be retained.  Initial
ideas
are that chown should still strip off these bits if the group is changed
to
something different because I think if it isn't changed then it presents
a
small security hole in the OS.

And finally: Wes mentioned, correctly, that dealing with suid,sgid might
not work favorably on some platforms like Ultrix.  My thoughts on this
are: I agree.  chmod in netatalk should *not* try to directly set any of
the special bits.  (such as modes |= 07700)  instead all modes should
be calculated using the permissions that *already* exist for that file
or
directory.

I would also like to see this in the a18 patches:

in unix.c somewhere:

#define DIR_PERM_DENY  04002   /* dont allow suid! and don't allow
unlimited writes */
#define DIR_PERM_FORCE 00660   /* we desire drw-rw---- in this share if
possible    */
#define FIL_PERM_DENY  07000   /* files are limited to r, w, or x in
this share     */
#define FIL_PERM_FORCE 00660   /* files should be rw to insure access by
group      */
#define MAC_MASK       00666   /* mac only specify read/write */

then these masks could be used when calculating modes such that:

finalmode = (~DIR_PERM_DENY & (st.st_mode | DIR_PERM_FORCE)) &
            (desired_mode | ~MAC_MASK)

the first part (~DIR_PERM_DENY & (st.st_mode | DIR_PERM_FORCE)) would
take the current mode of the dir, add to it all permissions that
you must have and then remove all the permissions that you don't want.
(This is the conservative route incase ALLOW and FORCE overlap).

the second part (desired_mode | ~MAC_MASK) builds a mask that consists
of 1 or 0 in the positions that the Mac can specify (read/write) and
1's in all other positions.  the conjunction of the two parts gives
you correct bits in the position that the Mac can specify, It adds bits
to any permission that you know you must have and strips bits from the
positions that you know you must not have and any remaining bits not
covered by the previous three things are inherited from the directories
present permissions.

This way Ultrix users or other platforms which have no knowledge of
certain bits can deal with it.  All you have to do is specify the
defines correctly.

In my case (linux) I would use the above values and manually set the
suid and sgid bits in the top most directory of the volume and the
above permissions would keep everything accessible to the group users
because the sgid bit would be inherited down the tree do to st.st_mode.

Does that make sense?

I'm going to try and use a. sun's patch and include this for files and
directories.

- Jeff

---

From: [email-masked]
Date: Fri, 07 Nov 1997 21:18:22 -0500

The implementation that I suggest is that on those systems that support
it, setgid is always on.  This is closer to Mac semantics, and thus
better.  Moreover, you should not grab permissions from the containing
folder, as they are also controlled by the Finder.  In other words, the
spec for FPCreateDir should be followed.  Check out

http://devworld.apple.com/ngs/lpp/adrpub/docs/dev/opentransport/docs/Inside_AppleTalk.pdf

:wes

---

From: "Amarendranath <Amar> Vadlamudi" <[email-masked]>
Date: Wed, 12 Nov 1997 17:21:12 -0500 (EST)

I'm using  netatalk1.4b2 with the two official patches (the Solaris EAGAIN
and the MacOS8 dancing icons) applied to it. This is in a Kerberos/AFS
environment.

I know that the "AFS Privileges" program distributed with the
kerberos-AFS.sit.hqx on terminator.rs.itd.umich.edu used to work well with
MacOS-7.6.

However, after upgrading to MacOS8, the program just starts up, and stays
in the spinning watch dial mode, before it locks up my machine. In some
cases I have had it show the privileges with a whole lot of "i", "1", "0"
symbols in the negative rights box. If I try to do anything after that,
the program locks up.

Has anyone else seen this behaviour ? Is there any recommended fix or any
suggestions ? Is anyone using AFS Privileges version 1.50 with MacOS8 and
netatalk1.4b2 and having no trouble ?

Thanks in advance
--Amar

####################################################################
Amarendranath Vadlamudi				Phone: 301-405-6597
Institute for Systems Research			FAX:   301-314-9920
University of Maryland				Email: [email-masked]