> > [..] > > [Jonathan Dickinson] > > Indeed it is. But think of the most basic server: FTP, you simply > can't do > > it without impersonation. I think another way around it is as > follows: > > > > FTP > Creates (FSProc) with user supplied credentials (a process > cannot > > change its own user context) > > > Denies All (Explicit declination, that right cannot be granted > unless > > by the FTP Proc) > > > Allows FS Access (Explicit approval, because we are the FTP > Proc) > > > Initializes FSProc > > > > FSProc > Go and does stuff on the FS. > > ...or we could just give the ftp server (on an application level) the > right to write in a specific directory and not let it impersonate > anyone.. > this way it could never do anything unexpected.. [Jonathan Dickinson] There is a /slight/ problem with that. Let's look at it at the most basic and fundamental viewpoint. We have two users joe and jack. Joe and jack use NFS to access their home directories when they are out of the office. They obviously need to use the same username and password as their local account (or even better, it is as transparent as network domains are. Once you are logged in you never have to log in again: all your services are automatically activated - which is AFAIK impossible without impersonation). Without impersonation Joe could see Jack's home directory. How could we solve that? Make an API that allows us to authenticate a user through custom code:
Joe logs into NFS -> NFS knows where he can and can't go. Same for Jack. That is peachy, until you consider a few things. First of all, you have duplication of security data. We are storing access rights in both NFS and VFS. Bad if they go out of sync for some reason. Furthermore, once we write the security code for VFS we could copy-n-paste it into NFS. Also bad, what happens if we fix a security bug in one and not the other (one of the fundamentals of OOP). I know impersonation might be hydrocarbon technology, but how to we fix it? What can we do instead? Also consider a simple corporate mail website. We could authenticate a user as TheRootMailUser and make sure that we don't allow them access to each-other manually. Or we could log them as themselves and be rest-assured that the user only has access to one directory on the VFS. Any ideas? > > ----------------------------------------------------------------------- > -- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > SharpOS-Developers mailing list > SharpOS-Developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sharpos-developers ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ SharpOS-Developers mailing list SharpOS-Developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sharpos-developers
