On Wed, Jun 30, 1999 at 10:50:04AM +0200, Juan Antonio Martinez wrote:
> On Tue, 29 Jun 1999, Laszlo Vecsey wrote:
> > 
> > Simple way to do that is to use the 'cp -a' unix command -- get both
> > partitions mounted on a system (the real /usr, and the coda mounted
> > partition), and copy between them with that command to preserve
> > everything. 
> > 
> 	Sorry: seems not explained enought: as coda administrator just did a
> 'cp -a' ( tar, cpio, and every variations ) and copy was fine, but when from
> client try to use any command, the owner is allways "coda" and setuid
> perms doesn't work. In fact, when "--preserve" option is given, get thousands
> of errors like "cp: cannot restore permission XXXX on file YYYY". Seems that 
> I must define all entries of /etc/passwd into list of coda users, and same 
> with /etc/group entries.... but groups in coda are negative numbers... :-(

Coda does not use the unix group and mode attributes for access control.
And I'm not sure whether the list of coda users needs to be in sync with
/etc/passwd. As far as I know, Coda doesn't try to interpret the uid/gid
attributes of a file. Also, Coda groups are never seen by a client but
they are translated into user specific access rights by the server.

Members of the group System:Administrators should be able to change the
ownership of files in Coda, which allows cp -a, tar, or cpio to copy
files with the correct ownership, but the VFS layer of the kernel
sometimes wants to have control as well, so you might need to be logged
in as `root'.

I do not know what the precise state of the access permission checks
is. As far as I know the mode flags on files/directories are not taken
into account. Setuid binaries are currently a relatively unexplored
area, where until a few months ago they were even explicitly disallowed.
There are many possible security problems related to allowing setuid
binaries in any distributed filesystem. If a user can create a setuid
root binary on any machine, he could use this to compromise the security
of other machines that share the same tree.

> 	My idea was not to define any user, just use anonymous coda login to
> read and execute commands from coda's copy of /usr directory. Don't know how
> to do this... even more don't know if this is possible

Just try to chown/chmod the setuid binaries while you are logged in as
root and are in posession of a coda-administrator token. For ono-setuid
binaries, ownership doesn't matter, and access is controlled by the ACL
on the directory.

# clog sysadm
password: ......
# ctokens
Local uid: 0
Coda user id: 500
# chown root /coda/usr/sbin/traceroute
# chmod u+s /coda/usr/sbin/traceroute
# ls -l /coda/usr/sbin/traceroute
-rwsr-xr-x   1 root     nobody    19230 Apr 27  1998 /coda/usr/sbin/traceroute

Jan