Date: Mon, 06 Jan 2003 19:54:47 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Julian Elischer <julian@elischer.org> Cc: Pawel Jakub Dawidek <P.Dawidek@prioris.mini.pw.edu.pl>, freebsd-hackers@freebsd.org Subject: Re: Caching [sugestion]. Message-ID: <3E1A4F87.2CE21B4A@mindspring.com> References: <Pine.BSF.4.21.0301061653580.4845-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote: > I vaguely remember that Linux keeps teh path used aroud on openned file > descriptors some how but I don't remember the details. It stores the path reference in the per process open file table, if you insist that it do so. Then it does a huge amount of work to carry it around. This is a lot easier on Linux, actually, because there is only a single method of copying in paths into kernel space, and it's only used for paths. In FreeBSD, there's copyinstr(), and it's used for a huge amount of crap, not just path names (e.g. NFS, mount args, and other terrible uses, where strings should not actually be in the kernel, proper, anyway). So it's not like you can trap it into a reference-counted path structure that gets passwed around after the copyinstr() (like an XInternAtom). > > We want to permit those operations: > > - opening file /etc/master.passwd for read only, > > - opening files that match to /tmp/temp.* for write, > > - changing mode of files /tmp/temp.* to '0666', BUT via fchmod(2). > > > > How to do that correct? > > There is no chance to do this in simple, clean way. > > you would have to attach a 'chmod capability' to the file descriptor > when you open it.. in other words it would be pre-decided at open time. > > Even if you remembered what name was used when you openned it you would > have no proof that it still had that name when you do the chmod. Or, worse... that the file was not deleted and recreated with the same name, such that the reference was lost, but the capability was not. Basically, you could violate a security model simply by creating a file where you knew a file was likely to be, unlinking it (but keeping the open reference), and then applying the capability that was cached against the new file. One example would be for the POSIX domain socket used for local X Server connections, with which you could then subvert the console. Basically this boils down to the fact that you can't trust cached data, and the information can only be used for advisory purposes, not for the implementation of mandatory access controls. If you wanted to implement MACs, you would need to go even further, and add a "deleted" flag to file system objects, so that you could not intentionally collide created-and-deleted-while-open and yet-to-be-created objects, in order to subvert MACs... either you have to not cache the information, or you have to guaranteed that the cache can not, under any circumstances, contain stale data. FWIW: I implemented NetWare inherited rights in a file system based on the SVR4 UFS implementation For this to work, I implemented caching of the parent directory for file system objects, to deal with hard links (as I have repeatedly suggested in this thread). This is not a new problem, and there is no such thing as a satisfying legacy implementation. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E1A4F87.2CE21B4A>