Subject: [netatalk-admins] when uid/gid == 0
From: a sun (asun@saul7.u.washington.edu)
Date: Fri Sep 04 1998 - 14:10:38 EDT
hi all,
i see a number of different solutions to the uid/gid issue. one is
sort of hackish but wouldn't require any intervention while the others
would require more administrative work. i was wondering what people's
thoughts on this might be.
the problem:
uid/gid == 0 need to be interpreted as "ignore uid/gid
permissions, respectively"
on unix machines, however, 0 really means root. as a result, we
can't use that to signify anything.
possible solution 1:
we can designate a generic user/group to signify "ignore
permissions." unfortunately, it's not possible on most machines
for a user to chown to another user. in addition, people will need
to be added to the generic group list for chgrp to
work. furthermore, if a chown does actually work, it will leave a
directory that no one can change permissions on anymore.
as a result, this solution doesn't cut it.
possible solution 2:
this still has the problem that only a particular user can
actually change the permissions on a directory, but it requires
the least amount of administration. it's also the most hackish. we
can use a couple of the special permissions bits to signify
special uid/gid permission modes. in this case, the sticky bit
would signify uid = 0, and the setuid bit would signify gid =
0. then, all the permission changing code would just check for
these bits and make the user/group bits follow the other bits.
i don't believe that the setuid bit actually gets used anywhere
for directories. is this correct? in addition, we get the added
benefit that using the sticky bit on directories gives us
something similar to what we want with multiple users of a
directory.
possible solution 3:
we combine the sticky bit part of #2 with the special group part
of #1. this would get around any special properties of setuid
directories.
possible solution 4:
we could have a root process running around that handles this
case. all it would do is broker requests for #1. such a situation
has all kinds of security implications, so i'm wary of
implementing such a beast. furthermore, it would break on nfs
volumes.
as you can probably tell, i'm for #2. comments?
-a
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:33:14 EST