gwyn@BRL.ARPA (VLD/VMB) (09/21/87)
If anyone needs a public-domain implementation of getcwd(), I now have one I can send you. - Gwyn@BRL.MIL
peter@ficc.uu.net (Peter da Silva) (04/04/89)
One thing that really would make things a lot easier would be a fchdir()
call, that took a file descriptor and tried to chdir to it. All the info
that UNIX needs for the chdir is available via the fd.
Then you could do this:
cwfd = open(".", 0);
/* chdir around building cwd */
fchdir(cwfd);
close(cwfd);
One of the few features AmigaDOS has over UNIX...
--
Peter da Silva, Xenix Support, Ferranti International Controls Corporation.
Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180.
Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.jfh@rpp386.Dallas.TX.US (John F. Haugh II) (04/05/89)
In article <3675@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >One thing that really would make things a lot easier would be a fchdir() >call, that took a file descriptor and tried to chdir to it. All the info >that UNIX needs for the chdir is available via the fd. Cromix worked this way, perhaps not with a fchdir() call, but most of the system calls under Cromix had file descriptor versions. However ... all of the information needed for a chdir() is not present in the file descriptor. It is possible to be handed a file descriptor which you would not be able to have opened because some component of the search path denies access now, but at some point in the past did allow access. -- John F. Haugh II +-Quote of the Week:------------------- VoiceNet: (214) 250-3311 Data: -6272 | "Porsche does not recommend InterNet: jfh@rpp386.Dallas.TX.US | exceeding any speed limits" UucpNet : <backbone>!killer!rpp386!jfh +-- -- Porsche Ad ------------
ed@mtxinu.COM (Ed Gould) (04/05/89)
>>One thing that really would make things a lot easier would be a fchdir() >>call, that took a file descriptor and tried to chdir to it. >However ... all of the information needed for a chdir() is not present >in the file descriptor. It is possible to be handed a file descriptor >which you would not be able to have opened because some component of >the search path denies access now, but at some point in the past did >allow access. Worse than that, the permission required to open a directory is "r" (since one may not open a directory for writing), whereas the permission required to change to one is "x". Hence, Unix protection would be completely violated by the existance of fchdir(). -- Ed Gould mt Xinu, 2560 Ninth St., Berkeley, CA 94710 USA ed@mtxinu.COM +1 415 644 0146 "I'll fight them as a woman, not a lady. I'll fight them as an engineer."
arosen@hawk.ulowell.edu (MFHorn) (04/05/89)
From article <811@mtxinu.UUCP>, by ed@mtxinu.COM (Ed Gould): > >It is possible to be handed a file descriptor > >which you would not be able to have opened because some component of > >the search path denies access now, but at some point in the past did > >allow access. > > Worse than that, the permission required to open a directory is "r" > (since one may not open a directory for writing), whereas the > permission required to change to one is "x". Hence, Unix protection > would be completely violated by the existance of fchdir(). Why can't the kernel check access permissions *at the time* of the fchdir() call just like it does for chdir() and open()? There is a function in the BSD kernel called iaccess() that is called every time one of these (and maybe other) system calls are made. It is passed a pointer to an inode struct and the type of access being requested (read, write, execute). I see no compromise in security. -- Andy Rosen | arosen@hawk.ulowell.edu | "I got this guitar and I ULowell, Box #3031 | ulowell!arosen | learned how to make it Lowell, Ma 01854 | | talk" -Thunder Road RD in '88 - The way it should've been
flee@shire.cs.psu.edu (Felix Lee) (04/05/89)
In article <3675@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >One thing that really would make things a lot easier would be a fchdir() >call, that took a file descriptor and tried to chdir to it. All the info >that UNIX needs for the chdir is available via the fd. This would open up holes with chroot(), but anyway... You need another open() mode, O_EXEC, open for execution. Then you could fchdir(), fexecve(), and so forth. With a little work, you could then replace all the standard system calls with library routines that call the corresponding f-function. Then knowledge of path names would be localized to the open() function (making it easier to add file access hooks). flink(), funlink(), and frename() are problematical because you also need descriptors to the directories involved, unless you attach knowledge of name and location to file descriptors. Probably not worth the effort. Now if you want to come up with a more powerful model of data storage that lets you layer Unix filesystem semantics on top of it... (Aside from all that, pushdir()/popdir() routines would be handy.) -- Felix Lee flee@shire.cs.psu.edu *!psuvax1!shire!flee
schwartz@shire.cs.psu.edu (Scott Schwartz) (04/05/89)
In article <811@mtxinu.UUCP>, ed@mtxinu (Ed Gould) writes: > > >>One thing that really would make things a lot easier would be a fchdir() > >>call, that took a file descriptor and tried to chdir to it. > >Worse than that, the permission required to open a directory is "r" >(since one may not open a directory for writing), whereas the >permission required to change to one is "x". Hence, Unix protection >would be completely violated by the existance of fchdir(). As long as we have entered the magical world of unix++, how about this: Add a new flag to open, O_EXEC, that would permit opening a file for execution only. Then to do an fchdir() you would first open the directory for execution. Similarly, fexecve() would take a descriptor opened for execution. "Open for execution" would be operationally defined as "can only be passed to fchdir(), fexecve(), or close()". I consider the argument that "permissions on the object might have changed between open() and fchdir()" to be specious. This is already the case with files and (even worse) devices, so we might as well accept the precident. Unless someone wants to implement fvhangup(), that is... :-) Frankly, I think permitting more system calls to take fd arguments rather than pathnames would be a big win. It certainly seems more logical in most cases. P.S. Given that directories are chdir-able iff they are marked executable, why do sh/csh/et.al. require that you type "cd"?? Just execute the directory by chdir-ing to it!
danl@cbnewsc.ATT.COM (daniel.r.levy) (04/05/89)
In article <811@mtxinu.UUCP>, ed@mtxinu.COM (Ed Gould) writes:
< >>One thing that really would make things a lot easier would be a fchdir()
< >>call, that took a file descriptor and tried to chdir to it.
< >However ... all of the information needed for a chdir() is not present
< >in the file descriptor. It is possible to be handed a file descriptor
< >which you would not be able to have opened because some component of
< >the search path denies access now, but at some point in the past did
< >allow access.
< Worse than that, the permission required to open a directory is "r"
< (since one may not open a directory for writing), whereas the
< permission required to change to one is "x". Hence, Unix protection
< would be completely violated by the existance of fchdir().
Umm, somehow SUNOS 4.0 manages to have a fchdir(), without creating a gaping
security hole. I tested it; it won't let me fchdir() into a mode 444 directory
even though I can open a file descriptor for reading onto that directory.
Granted, it has no way of knowing the search path, and could get you into a
directory, still having execute permission to you, that you had successfully
opened earlier but which you could not open now. But you could also have
fork()'ed earlier and had the child chdir() into the once-accessible directory,
or into its parent if the directory were read-only then and only now has become
searchable. Then you could communicate with that child process via some
interprocess communication method to get it to do its dastardly deeds, so
the fchdir() "hole" isn't any more of a hole than exists already.
Note: SUNOS 4.0 also allows fchdir() to be disabled, by means of turning
on auditing. The call will always fail in this case.
--
Dan'l Levy UNIX(R) mail: att!ttbcad!levy, att!cbnewsc!danl
AT&T Bell Laboratories
5555 West Touhy Avenue Any opinions expressed in the message above are
Skokie, Illinois 60077 mine, and not necessarily AT&T's.peter@ficc.uu.net (Peter da Silva) (04/05/89)
In article <3675@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >One thing that really would make things a lot easier would be a fchdir() >call, that took a file descriptor and tried to chdir to it. All the info >that UNIX needs for the chdir is available via the fd. In article <14689@rpp386.Dallas.TX.US>, jfh@rpp386.Dallas.TX.US (John F. Haugh II) writes: > However ... all of the information needed for a chdir() is not present > in the file descriptor. It is possible to be handed a file descriptor > which you would not be able to have opened because some component of > the search path denies access now, but at some point in the past did > allow access. That's an issue worth considering, but I'm not sure that it's really a security problem. After all, you could always spawn a child in a directory and send it messages over a pipe. Same thing, just a little more complex. It would be really nice to be able to pass an fd to another program, too. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
guy@auspex.auspex.com (Guy Harris) (04/05/89)
>Worse than that, the permission required to open a directory is "r" >(since one may not open a directory for writing), whereas the >permission required to change to one is "x". Hence, Unix protection >would be completely violated by the existance of fchdir(). Oh dearie me. From SunOS 4.0: NAME chdir - change current working directory SYNOPSIS int chdir (path) char *path; int fchdir (fd) int fd; DESCRIPTION chdir() and fchdir cause a directory to become the current working directory, that is, the starting point for pathnames not beginning with `/'. In order for a directory to become the current directory, a process must have execute (search) access to the directory. The path argument to chdir() points to the pathname of a directory. The fd argument to fchdir is the open file descriptor of a directory. RETURN VALUE Upon successful completion, a value of 0 is returned. Oth- erwise, a value of -1 is returned and errno is set to indi- cate the error. WARNING fchdir is provided as a performance enhancement and is guaranteed to fail under certain conditions. In particular, if auditing is active the call will never succeed, and EIN- VAL will be returned. Applications which use this system call must be coded to detect this failure and switch to using chdir() from that point on. Fortunately, "fchdir" requires you to have execute permission on the directory in question, so you're safe there, even if it won't let you change to some directories to which you could otherwise change....
flee@shire.cs.psu.edu (Felix Lee) (04/05/89)
In article <12625@swan.ulowell.edu>, arosen@hawk.ulowell.edu (MFHorn) writes: >Why can't the kernel check access permissions *at the time* of the >fchdir() call just like it does for chdir() and open()? This is fine (in fact SunOS4.0 does this), except you can chdir() to directories you can't open(). Unless you extend open(), fchdir() is less functional than chdir(). -- Felix Lee flee@shire.cs.psu.edu *!psuvax1!shire!flee
flee@shire.cs.psu.edu (Felix Lee) (04/06/89)
In article <3684@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) writes: >It would be really nice to be able to pass an fd to another program, too. Surprise! sendmsg() in 4.3bsd lets you do this. SunOS4.0 looks like it may also. See the recv(2) man page, in the paragraph describing msg_accrights. -- Felix Lee flee@shire.cs.psu.edu *!psuvax1!shire!flee
peter@ficc.uu.net (Peter da Silva) (04/06/89)
In article <FLEE.89Apr4223010@shire.cs.psu.edu>, flee@shire.cs.psu.edu (Felix Lee) writes: > flink(), funlink(), and frename() are problematical because you also > need descriptors to the directories involved, unless you attach > knowledge of name and location to file descriptors. Maybe funlink() and frename(), but flink() would just need the device an inode number. Hey, you're right. UNIX++ is gonna be pretty cool :->. It's looking more and more like AmigaDOS. Now how about adding asynchronous I/O and using mapped files to move SYSV's streams/queues into the file system...? -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
chris@mimsy.UUCP (Chris Torek) (04/06/89)
In article <FLEE.89Apr4223010@shire.cs.psu.edu> flee@shire.cs.psu.edu (Felix Lee) writes: >You need another open() mode, O_EXEC, open for execution. Then you >could fchdir(), fexecve(), and so forth. ... [but] >flink(), funlink(), and frename() [would remain] problematical ... Actually, flink would be no problem even now. (fsymlink, on the other hand, has the same problem as funlink and frename.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
les@chinet.chi.il.us (Leslie Mikesell) (04/06/89)
In article <3675@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >One thing that really would make things a lot easier would be a fchdir() >call, that took a file descriptor and tried to chdir to it. All the info >that UNIX needs for the chdir is available via the fd. > Better yet would be a per-process *name* of the current working directory stored somewhere, built according the the way you happened to get there. This would make getcwd() amount to printing static data instead of the contortions it does now, and as a side effect, it would make ".." mean something unsuprising in the presence of linked directories. Is there some reason this isn't done? Les Mikesell
john@frog.UUCP (John Woods) (04/06/89)
In article <811@mtxinu.UUCP>, ed@mtxinu.COM (Ed Gould) writes: >>>One thing that really would make things a lot easier would be a fchdir() >>>call, that took a file descriptor and tried to chdir to it. >>However ... all of the information needed for a chdir() is not present >>in the file descriptor. It is possible to be handed a file descriptor >>which you would not be able to have opened because some component of >>the search path denies access now, but at some point in the past did >>allow access. This objection had occurred to me also, but isn't necessarily SO bad, since changing access permissions on directories doesn't cause you to lose your current working directory. > Worse than that, the permission required to open a directory is "r" > (since one may not open a directory for writing), whereas the > permission required to change to one is "x". This one is a killer. Perhaps a better model might be a pushd()/popd() arrangement (perhaps even with a swapd()). A stack depth of 2 is enough to make it useful for getcwd(). You lose the ability to necessarily shut a process out of a directory if it happens to lose it, but that doesn't seem too much a loss; you don't lose the distinction between r and x access modes. A stack depth greater than two seems to be to start on a "slippery-slope" problem; the more you allow, the more resources a badly written process can take up, but the more uses it can have (though to use it for a shell directory stack, you would want an arbitrary (or at least very large) limit, which is clearly unacceptable). -- John Woods, Charles River Data Systems, Framingham MA, (508) 626-1101 ...!decvax!frog!john, john@frog.UUCP, ...!mit-eddie!jfw, jfw@eddie.mit.edu Remainder Khomeini!
bengsig@oracle.nl (Bjorn Engsig) (04/06/89)
Please keep this discussion out of comp.databases. -- Bjorn Engsig, ORACLE Europe \ / "Hofstadter's Law: It always takes Path: mcvax!orcenl!bengsig X longer than you expect, even if you Domain: bengsig@oracle.nl / \ take into account Hofstadter's Law"
flee@shire.cs.psu.edu (Felix Lee) (04/06/89)
In article <16758@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes: >Actually, flink would be no problem even now. (fsymlink, on the other >hand, has the same problem as funlink and frename.) Yes, I thought of this after I wrote [that flink would be a problem]. Imagine. You've unlinked a file right after you opened it, and now you've changed your mind. You really do want to keep the data. What do you do? We can help you! We're FLINK! int flink(int fd, char * path); -- Felix Lee flee@shire.cs.psu.edu *!psuvax1!shire!flee
ekrell@hector.UUCP (Eduardo Krell) (04/07/89)
In article <8136@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >Better yet would be a per-process *name* of the current working >directory stored somewhere, built according the the way you >happened to get there. This is what ksh does (it stores it in $PWD). pwd is a ksh builtin which just prints $PWD. It's harder to do in the kernel because pathnames can be very long and you don't want to increase the size of the process structure by that much. >as a side effect, it would make ".." mean something unsuprising in the >presence of linked directories. Is there some reason this isn't done? You would have to convince the powers to be (BSD and System V folks) that this is the way ".." should behave. We went through this ".." war a while ago and there were people on both sides. We actually changed the meaning of ".." to work the way you want it to. We also changed getwd() and getcwd() so that instead of opening and closing ".." until it reaches the root, it looks up in the namei() cache which holds the component names for all current and root directories of all processes (thus, you can always look in the cache for the name of the current working directory by just following a linked list back to the root). Needless to say, this is much faster than opening and closing directories. Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {att,decvax,ucbvax}!ulysses!ekrell Internet: ekrell@ulysses.att.com
hm@uva.UUCP (HansM) (04/07/89)
In article <8136@chinet.chi.il.us] les@chinet.chi.il.us (Leslie Mikesell) writes:
]Better yet would be a per-process *name* of the current working
]directory stored somewhere, built according the the way you
]happened to get there. This would make getcwd() amount to printing
]static data instead of the contortions it does now,
Sure.
] and as a
]side effect, it would make ".." mean something unsuprising in the
]presence of linked directories.
]
]Les Mikesell
I am afraid that a symlink pointing to "../foo" would do very surprising
things if the meaning of ".." were decided on a per-process basis....
Hans Mulder hm@uva.uucp mcvax!uva!hmekrell@hector.UUCP (Eduardo Krell) (04/07/89)
In article <687@uva.UUCP> hm@uva.UUCP (Hans Mulder) writes: >I am afraid that a symlink pointing to "../foo" would do very surprising >things if the meaning of ".." were decided on a per-process basis.... And how do you feel when you're in /usr/include/sys and then "cd .." to find yourself in /sys ? (I'm assuming the standard BSD configuration where /usr/include/sys is a symbolic link to /sys/h). We had a symbolic link war some time ago. Let's not restart the whole thing again. Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {att,decvax,ucbvax}!ulysses!ekrell Internet: ekrell@ulysses.att.com
greywolf@unisoft.UUCP (The Grey Wolf) (04/07/89)
In article <4438@psuvax1.cs.psu.edu> schwartz@shire.cs.psu.edu (Scott Schwartz) writes: # In article <811@mtxinu.UUCP>, ed@mtxinu (Ed Gould) writes: # > # > >>One thing that really would make things a lot easier would be a fchdir() # > >>call, that took a file descriptor and tried to chdir to it. # > # >Worse than that, the permission required to open a directory is "r" # >(since one may not open a directory for writing), whereas the # >permission required to change to one is "x". Hence, Unix protection # >would be completely violated by the existance of fchdir(). # # As long as we have entered the magical world of unix++, how about # this: Add a new flag to open, O_EXEC, that would permit opening a file # for execution only. Then to do an fchdir() you would first open the # directory for execution. Similarly, fexecve() would take a descriptor # opened for execution. "Open for execution" would be operationally # defined as "can only be passed to fchdir(), fexecve(), or close()". This looks like a good idea... # # [ more about open(), fchdir... et al. ] # # Frankly, I think permitting more system calls to take fd arguments # rather than pathnames would be a big win. It certainly seems more # logical in most cases. Do you really mean "rather than" as "instead of"? I like the idea of being able to do either/or, depending on what you wanted to do. I mean, if they were "instead of", and chmod() were eliminated so that only fchmod remained, how would you change the mode of a file that was mode 000? You wouldn't be able to O_RDWR or O_EXEC the file/directory and therefore couldn't gain a valid file descriptor to pass to fchmod(). I think that the option of f() commands should remain open. # # P.S. Given that directories are chdir-able iff they are marked # executable, why do sh/csh/et.al. require that you type "cd"?? # Just execute the directory by chdir-ing to it! At the College of Marin, some friends of mine (and later myself) modified the 4.1 c shell (Yeah, I *know* it's not everyone's favourite, but it IS mine! (no accounting for taste?)) to do just that. I later incorporated the modification into the 4.3 csh. It depended upon a variable called "autogoto". bit of trivia my roommate (a main writer of dsh) prefers not to use this feature, since it has stung him too many times. He administers a system on which such users as "ls" exist, for example. He's in the main users directory, and types "ls" and receives nothing but a prompt. Imagine his initial shock -- "OH NO! WHERE ARE ALL THE USERS' DIRECTORIES!!!???"...) Roan Anderson, Third Assistant Technogeek to the Third Assistant Technogeek. (gotta watch out for #3 sometime :-) -- ...TheysaidDoyouseethebiggreenglowinthedarkhouseuponthehill?andIsaidYesIseethebiggreenglowinthedarkhouseuponthehillTheresabigdarkforestbetweenmeandthebiggreenglowinthedarkhouseuponthehillandalittleoldladyonaHoovervacuumcleanersayingIllgetyoumyprettyandyourlittledogTototoo I don't even *HAVE* a dog Toto...
schwartz@shire.cs.psu.edu (Scott Schwartz) (04/07/89)
I wrote: # Frankly, I think permitting more system calls to take fd arguments # rather than pathnames would be a big win. It certainly seems more # logical in most cases. In article <2001@unisoft.UUCP>, greywolf@unisoft (The Grey Wolf) writes: >Do you really mean "rather than" as "instead of"? I like the idea of >being able to do either/or, depending on what you wanted to do. I mean, >if they were "instead of", and chmod() were eliminated so that only >fchmod remained, how would you change the mode of a file that was mode >000? You wouldn't be able to O_RDWR or O_EXEC the file/directory and >therefore couldn't gain a valid file descriptor to pass to fchmod(). >I think that the option of f() commands should remain open. Good point. Ideally the "fd" mechanism could completely subsume the "path" mechanism. Realistically, you would probably include the non-fd versions of the all the new syscalls for compatability, and to save a call to open/close in common cases. To answer the fchmod problem we could do a couple things. For one thing, we could introduce O_CHMOD to open for mode changes. The open would succeed iff the opener had permission to do a chmod. In general maybe we want a way to open a file for identification but not necessarily access: O_NAMEI anyone? O_NOP? O well. :-) -- Scott Schwartz <schwartz@shire.cs.psu.edu>
peter@ficc.uu.net (Peter da Silva) (04/07/89)
In article <2001@unisoft.UUCP>, greywolf@unisoft.UUCP (The Grey Wolf) writes: > Do you really mean "rather than" as "instead of"? I like the idea of > being able to do either/or, depending on what you wanted to do. I mean, > if they were "instead of", and chmod() were eliminated so that only > fchmod remained, how would you change the mode of a file that was mode > 000? You wouldn't be able to O_RDWR or O_EXEC the file/directory and > therefore couldn't gain a valid file descriptor to pass to fchmod(). > I think that the option of f() commands should remain open. How about O_TOKEN which returns a fd you can't do anything to until you do another open on it. Soirt of like an RMX file token or an AmigaDOS file lock. Have to call the fd version of open something other than fopen or fdopen, though. This would make 'dup' into fd_open(fd, O_CLONE), where O_CLONE means 'same flags as the first fd'... Do this cleverly enough and almost all the regular calls can actually use the new calls... you just need to keep 'open' around so you can get the fd in the first place: link(name, newname) char *name, *newname; { int fd; fd = open(name, O_TOKEN); if(fd >= 0) { retval = fd_link(fd, newname); close(fd); } else return -1; } -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
guy@auspex.auspex.com (Guy Harris) (04/08/89)
>Surprise! sendmsg() in 4.3bsd lets you do this. SunOS4.0 looks like >it may also. I'd sure hope it does, since the code basically comes from some BSD release in the range [4.3BSD, 4.3-tahoe). SunOS 4.0, and other systems with the S5R3 streams code, will also let you pass file descriptors with streams (at least the code appears to try to support it, and the documentation claims it works; I haven't tried it, so I don't know if there are any bugs).
leo@philmds.UUCP (Leo de Wit) (04/08/89)
In article <2001@unisoft.UUCP> greywolf@unisoft.UUCP (The Grey Wolf) writes: [] |# |# P.S. Given that directories are chdir-able iff they are marked |# executable, why do sh/csh/et.al. require that you type "cd"?? |# Just execute the directory by chdir-ing to it! | |At the College of Marin, some friends of mine (and later myself) modified the |4.1 c shell (Yeah, I *know* it's not everyone's favourite, but it IS mine! |(no accounting for taste?)) to do just that. I later incorporated the |modification into the 4.3 csh. It depended upon a variable called "autogoto". | |bit of trivia |my roommate (a main writer of dsh) prefers not to use this feature, |since it has stung him too many times. He administers a system on which such |users as "ls" exist, for example. He's in the main users directory, and types |"ls" and receives nothing but a prompt. Imagine his initial shock -- |"OH NO! WHERE ARE ALL THE USERS' DIRECTORIES!!!???"...) Seems this system administrator has his PATH wrong. What if I, for example, $ ln -s /etc/shutdown /tmp/ls and he types 'ls' in /tmp? Leo.
guy@auspex.auspex.com (Guy Harris) (04/09/89)
>For one thing, we could introduce O_CHMOD to open for mode changes. >The open would succeed iff the opener had permission to do a chmod. No, not worth it. "fchmod" can - and does - already check whether you have permission to do a "chmod".
flee@shire.cs.psu.edu (Felix Lee) (04/09/89)
In article <1410@auspex.auspex.com>, guy@auspex.auspex.com (Guy Harris) writes: >>For one thing, we could introduce O_CHMOD to open for mode changes. >No, not worth it. "fchmod" can - and does - already check whether you >have permission to do a "chmod". Er, the point is to fchmod a file that you don't have permission to open. You need to open a file for no access (O_OPEN?). The idea is to localize file accesses to the open() call, making it easier to interpose user-level file access hooks. If open flags were orthogonal, then O_OPEN would be 0 and the various read/write/etc. modes would be or'ed together. -- Felix Lee flee@shire.cs.psu.edu *!psuvax1!shire!flee
dave@lethe.UUCP (Dave Brown) (04/10/89)
In article <3746@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: | How about O_TOKEN which returns a fd you can't do anything to until you | do another open on it. Soirt of like an RMX file token or an AmigaDOS | file lock. Have to call the fd version of open something other than | fopen or fdopen, though. | ... | Do this cleverly enough and almost all the regular calls can actually use | the new calls... you just need to keep 'open' around so you can get the | fd in the first place: Good idea. Historically, Unix made open out of "initiate" and "open", (since one rarely initiates a file without opening it), and allowed most operations on the file be done via a fd or a filepointer. It might make some sense to reinvent initiate, but I like the idea of an O_DONT_YOU_DARE_OPEN_THAT mode to open... --dave -- David Collier-Brown, | {toronto area...}lethe!dave 72 Abitibi Ave., | Joyce C-B: Willowdale, Ontario, | He's so smart he's dumb. CANADA. 223-8968 |
guy@auspex.auspex.com (Guy Harris) (04/11/89)
>>>For one thing, we could introduce O_CHMOD to open for mode changes. >>No, not worth it. "fchmod" can - and does - already check whether you >>have permission to do a "chmod". > >Er, the point is to fchmod a file that you don't have permission to >open. You need to open a file for no access (O_OPEN?). Er, the complaint wasn't that you don't need a new flavor of open, the complaint was that you don't need a new flavor of open *that's specific to "chmod", and that does permission checking*. From the article to which I was replying: For one thing, we could introduce O_CHMOD to open for mode changes. The open would succeed iff the opener had permission to do a chmod. O_OPEN is *all* you need; you don't need O_CHMOD and O_CHOWN and O_this and O_that, since the call that uses the file descriptor can check the permissions itself (and does, in the case of "fchmod", for example). O_CHMOD doesn't buy you anything worthwhile that O_OPEN doesn't; assuming it's worth adding O_OPEN, it's not worth adding O_CHOWN.
allbery@ncoast.ORG (Brandon S. Allbery) (04/11/89)
As quoted from <12625@swan.ulowell.edu> by arosen@hawk.ulowell.edu (MFHorn): +--------------- | From article <811@mtxinu.UUCP>, by ed@mtxinu.COM (Ed Gould): | > >It is possible to be handed a file descriptor | > >which you would not be able to have opened because some component of | > >the search path denies access now, but at some point in the past did | > >allow access. | > | > Worse than that, the permission required to open a directory is "r" | > (since one may not open a directory for writing), whereas the | > permission required to change to one is "x". Hence, Unix protection | > would be completely violated by the existance of fchdir(). | | Why can't the kernel check access permissions *at the time* of the | fchdir() call just like it does for chdir() and open()? +--------------- Because it can only check access to the specific inode -- *not* to the path to the inode. What happens if you have: chdir("/usr/spool/uucppublic"); fd = open(".", 0); chdir("/tmp"); ...do something... ...root makes /usr/spool mode 0700 owner bin... fchdir(fd); <-- succeeds BUT, under the present system: chdir("/usr/spool/uucppublic"); chdir("/tmp"); ...do something... ...root changes permissions as above... chdir("/usr/spool/uucppublic"); <-- FAILS! There is a distinction. The permissions on a file are dependent on the permissions of each component of the path; which means that two (hard) links to a file may have different *effective* permissions, if (say) one link is in a directory which is mode 0700 owner root and the other is in /tmp (mode 0777, or maybe 2777 or 3777 on more recent systems), *regardless* of the permissions on the file. (Symbolic links are another matter; a symbolic link contains a path, the permissions of whose components must be figured into it. Interestingly, a symlink itself has no relevant permissions; every one I've seen lstat()'s as mode 0000....) ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@<backbone> NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser
allbery@ncoast.ORG (Brandon S. Allbery) (04/12/89)
As quoted from <4438@psuvax1.cs.psu.edu> by schwartz@shire.cs.psu.edu (Scott Schwartz): +--------------- | In article <811@mtxinu.UUCP>, ed@mtxinu (Ed Gould) writes: | >Worse than that, the permission required to open a directory is "r" | >(since one may not open a directory for writing), whereas the | >permission required to change to one is "x". Hence, Unix protection | >would be completely violated by the existance of fchdir(). | | I consider the argument that "permissions on the object might have | changed between open() and fchdir()" to be specious. This is already | the case with files and (even worse) devices, so we might as well | accept the precident. Unless someone wants to implement fvhangup(), | that is... :-) +--------------- Having an open file on which permissions change doesn't affect the permissions of other, un-opened files. fchdir() *would* affect the effective permissions of other files, and is thus potentially more worrisome. +--------------- | P.S. Given that directories are chdir-able iff they are marked | executable, why do sh/csh/et.al. require that you type "cd"?? | Just execute the directory by chdir-ing to it! +--------------- The Principle of Least Surprise, I'd guess. My path on one system includes ~/bin, which contains a shell script called "mh" (for use in a windowing environment so I can click on the "Mail" icon to send or read mail. The environment isn't compatible with or as complete as X Windows, so xmh isn't an option); it also includes /usr/lbin, which contains a *directory* called "mh" wherein reside the MH executables. Now: if I type "mh" at a prompt, it will be treated as the shell script *or* as the directory, *depending on the order of my $PATH*. This is non-intuitive. ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@<backbone> NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser
allbery@ncoast.ORG (Brandon S. Allbery) (04/14/89)
As quoted from <3746@ficc.uu.net> by peter@ficc.uu.net (Peter da Silva): +--------------- | In article <2001@unisoft.UUCP>, greywolf@unisoft.UUCP (The Grey Wolf) writes: | > if they were "instead of", and chmod() were eliminated so that only | > fchmod remained, how would you change the mode of a file that was mode | > 000? You wouldn't be able to O_RDWR or O_EXEC the file/directory and | > therefore couldn't gain a valid file descriptor to pass to fchmod(). | | How about O_TOKEN which returns a fd you can't do anything to until you | do another open on it. Soirt of like an RMX file token or an AmigaDOS | file lock. Have to call the fd version of open something other than | fopen or fdopen, though. | | This would make 'dup' into fd_open(fd, O_CLONE), where O_CLONE means | 'same flags as the first fd'... | | Do this cleverly enough and almost all the regular calls can actually use | the new calls... you just need to keep 'open' around so you can get the | fd in the first place: +--------------- At the risk of being flamed for Political Incorrectness, I'll note that this sounds vaguely familiar. open(path, O_TOKEN) <------> shmget(key) fd_open(token, ...) <------> shmat(shmid, ...) I find myself wondering if AT&T knew what it was doing after all.... ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@<backbone> NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser
ka@june.cs.washington.edu (Kenneth Almquist) (04/16/89)
peter@ficc.uu.net (Peter da Silva) writes: > [Suggestion for O_TOKEN.] > > Do this cleverly enough and almost all the regular calls can actually use > the new calls... you just need to keep 'open' around so you can get the > fd in the first place: > > link(name, newname) > char *name, *newname; > { > int fd; > > fd = open(name, O_TOKEN); > if(fd >= 0) > { > retval = fd_link(fd, newname); > close(fd); > } > else > return -1; > } A good idea in principle, but the code you present here contains three rather obscure bugs which are worth pointing out in case someone decides to implement this. First, the open can fail because of a lack of open file descriptors, and EMFILE isn't one of the error codes that link is supposed to return. Second, there is no guarantee that the open system call will ever return; for example an open of a tty device blocks until carrier is present, and it may never be. Third, if a signal arrives between the open and the close, and the signal handler does a longjmp out of the link routine, the file descriptor will never be closed. The second problem is easily fixed by adding the O_NDELAY flag to the open call. The other two are harder. The third can be solved by blocking all signals before the open, and unblocking them after the close. The main problem with this is that, with a networked file system, you may want link to be interruptable. The first problem can be fixed by reserving the last file descriptor for routines like link. To do this, make the system calls refuse to allocate the last file descriptor under ordinary circumstances. Then allow the open call to allocate the last file descriptor if the O_USELAST flag is set. By convention, user code should not use O_USELAST. Putting this all together gives: link(name, newname) char *name, *newname; { int fd; int savemask; savemask = sigblock(~0); /* block all signals */ fd = open(name, O_TOKEN|O_NDELAY|O_USELAST); if(fd >= 0) { retval = fd_link(fd, newname); close(fd); sigblock(savemask); /* unblock signals */ return 0; } else { sigblock(savemask); return -1; } } Kenneth Almquist
greg@cantuar.UUCP (G. Ewing) (04/17/89)
The Grey Wolf (greywolf@unisoft.UUCP) writes: >Do you really mean "rather than" as "instead of"? I like the idea of Perhaps open() should be the only system call that takes a pathname, all others taking a file descriptor, with library routines to provide the rest. >how would you change the mode of a file that was mode >000? Open it with O_NOTHING, of course. ># Just execute the directory by chdir-ing to it! Once I created a directory called emacs to put my .el files in. Then I wondered why the emacs command wouldn't work. The shell saw this thing in the search path called emacs with the x bit on, and tried to execute it... I guess auto-chdir isn't such a silly idea. On the Mac, you run a program by double clicking it, and you open a folder by double-clicking it. You can also run a program by double clicking one of its documents. What would that correspond to in a shell? Greg Ewing Internet: greg@cantuar.uucp Spearnet: greg@nz.ac.cantuar Telecom: +64 3 667 001 x8357 UUCP: ...!{watmath,munnari,mcvax,vuwcomp}!cantuar!greg Post: Computer Science Dept, Univ. of Canterbury, Christchurch, New Zealand Disclaimer: The presence of this disclaimer in no way implies any disclaimer.
jfc@athena.mit.edu (John F Carr) (04/18/89)
In article <FLEE.89Apr16010720@shire.cs.psu.edu> flee@shire.cs.psu.edu (Felix Lee) writes: >2. The open may block. Kenneth Almquist suggests O_NDELAY, which is >fine. Another alternative is to say that O_TOKEN doesn't block; >blocking is only useful if you open for reading or writing. Suppose you are using NFS over a slow network? The directory lookups may take time, as will the actual open. The same problem exists with slow local media. You can't guarantee proper error reporting without blocking. -- John Carr "When they turn the pages of history, jfc@Athena.mit.edu When these days have passed long ago, bloom-beacon! Will they read of us with sadness athena.mit.edu!jfc For the seeds that we let grow?" --Neil Peart
cudcv@warwick.ac.uk (Rob McMahon) (04/18/89)
In article <FLEE.89Apr6112136@shire.cs.psu.edu> flee@shire.cs.psu.edu (Felix Lee) writes: >Imagine. You've unlinked a file right after you opened it, and now you've >changed your mind. You really do want to keep the data. What do you do? > >We can help you! We're FLINK! > int flink(int fd, char * path); I think I've said this before, but I think flink(2) would be really useful in conjuntion with open("...", O_CREAT|O_WRONLY|O_NOLINK, 0666) (or O_TEMP or something), which would create a file which had no directory entry. This would really clean up the creation of temporary files for things like file transfer programs, which then wouldn't have to try and think up temporary names, and wouldn't be in any danger of leaving garbage around in case they died or the system crashed. Programs that wanted temporary files which would automatically disappear on exit could use this instead of open/unlink. The `...' would have to be the destination of the intended flink, so that the file could be created on the right filesystem. Maybe the name of a directory could be allowed in this case for temporary files which were never going to be flinked. It would be best if flink acted like rename, atomically replacing an old filename if it existed. Or maybe this should be frename, since this conflicts with the existing `link' ? What do people think ? Would this be a useful addition ? Rob -- UUCP: ...!mcvax!ukc!warwick!cudcv PHONE: +44 203 523037 JANET: cudcv@uk.ac.warwick ARPA: cudcv@warwick.ac.uk Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England
flee@shire.cs.psu.edu (Felix Lee) (04/18/89)
In article <10671@bloom-beacon.MIT.EDU>, jfc@athena.mit.edu (John F Carr) writes: >Suppose you are using NFS over a slow network? [...] You can't >guarantee proper error reporting without blocking. Let me clarify. What I meant by "blocking" on open() is the blocking affected by the Berkeley O_NDELAY flag. open() will always wait for access to the inode (or vnode). O_NDELAY only affects opening tty devices and FIFOs. (In the Berkeley derivatives I'm familiar with). (Is it time to change the Subject: yet?) -- Felix Lee flee@shire.cs.psu.edu *!psuvax1!shire!flee
ka@june.cs.washington.edu (Kenneth Almquist) (04/19/89)
jfc@athena.mit.edu (John F Carr) writes: ] In article <FLEE.89Apr16010720@shire.cs.psu.edu> ] flee@shire.cs.psu.edu (Felix Lee) writes: ] ]> 2. The open may block. Kenneth Almquist suggests O_NDELAY, which is ]> fine. Another alternative is to say that O_TOKEN doesn't block; ]> blocking is only useful if you open for reading or writing. ] ] Suppose you are using NFS over a slow network? The directory lookups ] may take time, as will the actual open. The same problem exists with ] slow local media. You can't guarantee proper error reporting without ] blocking. The issue is not blocking temporarily while waiting for disk or network I/O to take place. The problem is that the open system call, rather than succeeding or reporting an error, can simply block forever. The O_NDELAY flag prevents this under both System V and BSD. If you run NFS (which is not part of either System V or BSD UNIX at this point), then the O_NDELAY flag won't help you. My suggestion: don't use NFS. Kenneth Almquist
guy@auspex.auspex.com (Guy Harris) (04/19/89)
>The issue is not blocking temporarily while waiting for disk or network >I/O to take place. The problem is that the open system call, rather than >succeeding or reporting an error, can simply block forever. The O_NDELAY >flag prevents this under both System V and BSD. If you run NFS (which is >not part of either System V or BSD UNIX at this point), then the O_NDELAY >flag won't help you. There is some confusion here. The "block forever" stuff applies to special files and FIFOs, not to regular files; while you can open a special file or FIFO that exists on a remote machine, the file in question refers to a local object. If you do an open on a special file that exists on an NFS file system, O_NDELAY most definitely *will* get passed to the *local* driver for that special file's device, and it will act on it just as if you'd opened a special file on a local file system (in fact, the driver has no idea that the file exists on a remote machine - which, for the case of a diskless machine, is the way it should be; if I open "/dev/console" on my diskless workstation, I want *my* console, not the server's console!). The same applies for FIFOs that exist on NFS file systems. (They act as rendezvous points for local processes only.) In either case, the local software, when seeing the O_NDELAY, will honor it if the file was an NFS file, as long as it would have honored it were it a local file. That is definitely true for FIFOs, at least under SunOS, and true of tty devices, at least.
allbery@ncoast.ORG (Brandon S. Allbery) (04/26/89)
As quoted from <10051@smoke.BRL.MIL> by gwyn@smoke.BRL.MIL (Doug Gwyn): +--------------- | In article <13563@ncoast.ORG> allbery@ncoast.UUCP (Brandon S. Allbery) writes: | >I find myself wondering if AT&T knew what it was doing after all.... | | Nah, the shm* objects are incompatible with fd-objects. +--------------- I know. In fact, that's part of my reasoning. AT&T added a new object space (IPC objects) for shared memory, message queues, and semaphores. Presumably they had a reason not to want to use the existing object space of file descriptors. I can imagine the following reasoning: * File descriptors aren't quite general enough to do what we want. * Changing fd's to be general (or perhaps flexible) enough will break things. * We can design an object space that *is* flexible enough. * Once we have done so, we can present them as separate object spaces for SVR2. * In future versions, we can start to convert file descriptors into a class of IPC objects... eventually ending up with a single object space again. Having done the latter, one could then use a single set of syscalls on the entire space... allowing, for example, a "file" IPC object to be treated either as a classical file, or mapped into the address space as shared memory, or even as a message queue. (And having message queues and files be semi- equivalent raises the possibility of defining pipes in terms of such hybrid objects. Note also that it resolves the current problem of file system objects which don't have file system names (e.g. sockets, or even pipes) and can even provide a version of /dev/fd/n in the bargain. The namespace of IPC objects is visible (but can and should be made more so), but not tied to the file system namespace. I would suggest that (again) the IPC name space is more general than the current file system name space (and again, incompatible). Thus, we would again want to have them separate initially, then gradually replace the less general with the more. The IPC name space would need to be revised, of course... 32 bits/name doesn't seem enough for large networks. I dunno, it was just a thought. On thinking it over, I find myself doubting that AT&T (or Sun, now) would actually do something so sensible. But the possibility *does* exist. ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@<backbone> NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser
boyd@necisa.necisa.oz (Boyd Roberts) (04/26/89)
What we really need is /dev/time. Opening it returns a descriptor refering to the system time inode. You can fstat() it and determine the current time from the modification time. Its modification time would be updated by clock(). A host of advantages would follow. date(1) would be "ls -l /dev/time | cut ..". This would move us ever closer to a true descriptor based OS... Boyd Roberts NEC Information Systems Australia boyd@necisa.necisa.oz ``When the going gets wierd, the weird turn pro...''
bzs@bu-cs.BU.EDU (Barry Shein) (04/26/89)
I remember teaching a systems programming course and, after going over the whole file system/file descriptor model getting into the SYSV shmem/semaphore/msg stuff. At the end of the lecture I asked a student who looked disturbed what the problem was, he said "it looks like it landed on Unix after taking off from Mars!" The (possibly true) story I had heard was the the whole interface was thrown together by a non-mainline group to support a (possibly internal) client at AT&T and ended up getting stuck in the mainline distributions. That is, it was never a plan but an accident of history somewhere back in the early SYSIII days. I can't imagine what the nervousness is about having these things in the file name space (not like anyone hesitated with FIFOs and that, IMHO, is a neat feature.) They obviously all needed a global name space and that's what the file system is there for. I would have preferred some extension of "non-persistant" objects, that is, file names (& inodes) which never leave main memory thus guaranteed to go away in the event of a system crash, they only live in the appropriate caches, only one bit needed in the buffer headers and a little code to skip past them. Would have made all sorts of objects like this cheaper and safer to implement (like lock files and some types of temp files.) Ah well, too late now I guess... -- -Barry Shein, Software Tool & Die There's nothing more terrifying to hardware vendors than satisfied customers.
schwartz@shire.cs.psu.edu (Scott Schwartz) (04/30/89)
In article <824@necisa.necisa.oz>, boyd@necisa (Boyd Roberts) writes: >What we really need is /dev/time. Opening it returns a descriptor refering >to the system time inode. You can fstat() it and determine the current >time from the modification time. Its modification time would be updated >by clock(). More logical to read it to get the time, don't you think? >This would move us ever closer to a true descriptor based OS... I think we need a good dose of Multics: Reading the time should be equivalent to accessing an object in virtual memory. In fact, the whole operating system system should behave like that, filesystem, system calls, and so on. Recently there was a discussion about the SysV shm* namespace vs the file descriptor namespace. The answer to the question "is this a good thing" is no. A real OS (taking no prisoners, here :-) needs only virtual memory. Everything else should be part of that. Shared memory should be part of the filesystem because the filesystem and memory are identical. In that case it is unnatural to have a separate access mechanism like the shm* stuff. -- Scott Schwartz <schwartz@shire.cs.psu.edu>
bill@twwells.uucp (T. William Wells) (04/30/89)
In article <4523@psuvax1.cs.psu.edu> schwartz@shire.cs.psu.edu (Scott Schwartz) writes:
: I think we need a good dose of Multics: Reading the time should be
: equivalent to accessing an object in virtual memory. In fact, the
: whole operating system system should behave like that, filesystem,
: system calls, and so on.
Ack, NO! All we need is one rogue pointer and almost ANYTHING can
happen!
That notion is attractive, but the separation produced by having
system calls means that a much smaller class of errors is likely to
do random things to your operating environment.
---
Bill { uunet | novavax } !twwells!billaglew@xenurus.gould.com (05/02/89)
>In article <4523@psuvax1.cs.psu.edu> schwartz@shire.cs.psu.edu (Scott Schwartz) writes: >: I think we need a good dose of Multics: Reading the time should be >: equivalent to accessing an object in virtual memory. In fact, the >: whole operating system system should behave like that, filesystem, >: system calls, and so on. > >Ack, NO! All we need is one rogue pointer and almost ANYTHING can >happen! > >That notion is attractive, but the separation produced by having >system calls means that a much smaller class of errors is likely to >do random things to your operating environment. > >--- >Bill { uunet | novavax } !twwells!bill Going further - performing all operations via a limited set of operations on files (augmented by ioctls) is defining the interface via DATA STRUCTURES. System calls, etc., are a functional interface. To repeat, there are two ways of defining interfaces: via DATA STRUCTURES, and via FUNCTIONS (or operations, etc.). Functional interfaces are more flexible - you can put a wrapper around a function to include augmented functionality. You can't do this to data structures unless you can get a trap on access. Eg. say we have a simple data structure, a stack implemented in an array. You can define it as "here is the array, and a current pointer variable - you add something to the stack by putting it in the array and incrementing the variable". Or you can define it via abstract operations PUSH and POP. Guess which is easier to change implementation. Adding functionality by read/write calls is sort of semi-functional -- it has a functional interface, but all the crucial detail is in the data structures that are read/written. If you do things that way, at the very least provide a functional approach to dissecting the data structures (not a data structure layout). Andy "Krazy" Glew, Motorola MCD, aglew@urbana.mcd.mot.com 1101 E. University, Urbana, IL 61801, USA. uunet!uiucdcs!mcdurb!aglew