Subject: Re: [netatalk-admins] special bits and such
From: Jeff Wiegley (jeff@w3-design.com)
Date: Fri Nov 07 1997 - 18:41:23 EST
a sun wrote:
>
> 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);
> }
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
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:28:01 EST