Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!usc!howland.reston.ans.net!usenet.ins.cwru.edu!eff!news.kei.com!news.byu.edu!cwis.isu.edu!u.cc.utah.edu!cs.weber.edu!terry From: terry@cs.weber.edu (A Wizard of Earth C) Newsgroups: comp.os.386bsd.development Subject: Re: Porting NetBSD to OS/2 and Windows NT Date: 22 Nov 1993 23:26:09 GMT Organization: Weber State University, Ogden, UT Lines: 52 Message-ID: <2crhqh$hl7@u.cc.utah.edu> References: <pcbsdCGuzuK.FF5@netcom.com> <2cpjp3$k89@u.cc.utah.edu> <CGw83t.3K3@dragon.dsh.org> NNTP-Posting-Host: cs.weber.edu In article <CGw83t.3K3@dragon.dsh.org> gary@dragon.dsh.org (Gary D. Duzan) writes: [ ... FFS inode data stored as OS/2 extended attributes ... ] > Mightn't such an approach cause security problems for programs >which assume the system is honoring the file ownership and permissions? >I would think that OS/2 programs would be able to access the files >regardless of the extended attributes, unless the files have some >other protection. /etc/master.password is one example. An OS/2 application user can get at any file, and will not honor FFS permissions on the file regarding access? Yes, this is true. Is this a problem? I don't think so; there are several ways the issue can be successfully ignored: 1) All native OS/2 applications are considerred to be SUID root. 2) OS/2 applications are not remotely runnable -- only applications which understand credentials structures and enforce permissions using the FFS model can be run remotely (since OS/2 applications can't be run remotely, this is automaitcally enforced). 3) This is a physical security issue for the machine itself; by the same token, it is possible to boot a DOS disk and run a disk editor to get at the data anyway, if you have access to the console. There is no way to prevent a breaking if someone can dismount your hard drive and read it binarily from another OS. The fact that OS/2 applications don't care about enforcing FFS/POSIX access constraints is functionally equivalent to saying "Doctor, it hurts when I do this". Don't do that. This is the same reason it is not smart to allow direct disk access to DOS emulators/windows on machines running OS/2, UNIX, BSD, or whatever. It is certainly not part of the requirements that the implementors reconcile credentials models between OS/2 and FFS. If this is a requirement to your mind, then you are mistaken; it is no more a requirement than being able to display 132 columns is a requirement of almost all of the VT100 emulators under DOS. The target use is as a portability environment, not an emulation environment (from what I've seen). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.