(Illustration by Gaich Muramatsu)
Hi, I have a question concerning the usage of real uid vs. effective (or file system) uid in venus. In coda release 5.3.20, venus seems to use real uid (ruid) in file access because it extracts the real uid from struct coda_cred by using CRTORUID(cred). However, in venus/vproc.h, there is the comment > For all filesystem use CRTORUID is used: for Linux we definitely > want to fsuid to be used for filesystem access. This however > breaks the old AFS semantics that if an "su" is performed you > retain tokens. Accordingly, for Linux, there is the definition > #define CRTORUID(cred) ((vuid_t)((cred).cr_fsuid)) which, indeed, makes venus to use fsuid instead of ruid. However, in the later CVS revisions, credentials handling has been streamlined and coda_cred has collapsed into a single uid value. So, in the kernel file .../fs/coda/upcall.c, in function alloc_upcall(), we have > inp->ih.uid = current->uid; This is the real uid. So, in the case of Linux, access control semantics seem to be changing since 5.3.20. My application works with 5.3.20 (I am running Linux 2.4.20). In order to get it to work with a newer CVS release of Coda, I changed the above line to inp->ih.uid = current->fsuid; This is about whose Coda tokens are used in file access, I assume (so, it is not directly or only related to your discussion about local access control at the Coda client). If by chance my observations mentioned above happened to make any sense, I would like to know the rationale behind this change. Personally, for now, I would be happy if 5.3.20 semantics were retained (until someone points out a huge security hole in using fsuid or euid :-)) Regards, Tapio ===================================================================== Tapio Suihko Technical Research Centre of Finland (VTT) Tapio.Suihko_at_vtt.fi Information Technology Tel. + 358 9 456 6078 P.O.Box 1203 (Tekniikantie 4B) GSM. + 358 40 552 9646 FIN-02044 VTT, FINLAND Fax. + 358 9 456 7028 =====================================================================Received on 2003-04-14 07:22:17