Re: revoke(2) redux...

2002-12-24 Thread David Malone
On Tue, Dec 24, 2002 at 03:52:05PM +0100, [EMAIL PROTECTED] wrote: > We can then provide revoke(2) as a wrapper: > > revoke(const char *name) > { > int fd, e; > > fd = open(name, O_RDONLY); Assuming you can open the thing name points to. I guess it might b

Re: revoke(2) redux...

2002-12-24 Thread Juli Mallett
* De: [EMAIL PROTECTED] [ Data: 2002-12-24 ] [ Subjecte: Re: revoke(2) redux... ] > revoke is used in most "login daemons", telnetd, getty and elsewhere. > > There is no way you can close the race between: > > revoke("/dev/ttyfoo"); > and >

Re: revoke(2) redux...

2002-12-24 Thread phk
In message <[EMAIL PROTECTED]>, Garrett Wollman writes: >< said: > >> Isn't there a pretty obvious race between the revoke() and the open() ? > >To the extent that the race matters, it is obviated by making sure >that only the current user has permission to open the device. If the >user somehow m

Re: revoke(2) redux...

2002-12-24 Thread Garrett Wollman
< There is no way you can close the race between: > revoke("/dev/ttyfoo"); > and > open("/dev/ttyfoo"); > Not even in init(8). There is always the risk that another process > opens the device between the two. If that process belongs to root then it doesn't matter. If that process b

Re: revoke(2) redux...

2002-12-24 Thread phk
In message <[EMAIL PROTECTED]>, "Paul A. Scott" writes: >> I think you missed the fine point in the "kick everybody *else* >> off" comment. > >Ahhh. I guess you mean that revoke() would change to do that. You're right, >I did miss your point. > >> The point is you cannot serialize against other pro

Re: revoke(2) redux...

2002-12-24 Thread Paul A. Scott
> I think you missed the fine point in the "kick everybody *else* > off" comment. Ahhh. I guess you mean that revoke() would change to do that. You're right, I did miss your point. > The point is you cannot serialize against other processes. But that's the point of serialization. Anyway, if init

Re: revoke(2) redux...

2002-12-24 Thread Paul A. Scott
> From: "Paul A. Scott" <[EMAIL PROTECTED]> > I think what's needed is some form of serialization > around revoke() and open(). I'm not a master of the init code, but it may be > that the code is inherently non-reentrant, so the original code would then > be okay. Or, it may use spltty()? Or som

Re: revoke(2) redux...

2002-12-24 Thread phk
In message <[EMAIL PROTECTED]>, "Paul A. Scott" writes: > >-- > >> From: Poul-Henning Kamp <[EMAIL PROTECTED]> >>>void setctty(char *name) { >>>(void) revoke(name); >>>if ((fd = open(name, O_RDWR)) == -1) { >> Isn't there a pretty obvious race between the revoke() and the open() ?

Re: revoke(2) redux...

2002-12-24 Thread Robert Watson
On Tue, 24 Dec 2002, Poul-Henning Kamp wrote: > Isn't there a pretty obvious race between the revoke() and the open() ? > > Wouldn't it in fact make much more sense if revoke(2) was defined as > > int revoke(int fd); /* kick everybody else off */ > > and the code above would look like:

Re: revoke(2) redux...

2002-12-24 Thread Paul A. Scott
-- > From: Poul-Henning Kamp <[EMAIL PROTECTED]> >>void setctty(char *name) { >>(void) revoke(name); >>if ((fd = open(name, O_RDWR)) == -1) { > Isn't there a pretty obvious race between the revoke() and the open() ? > Wouldn't it in fact make much more sense if revoke(2) was defi

Re: revoke(2) redux...

2002-12-24 Thread David Malone
On Tue, Dec 24, 2002 at 12:40:25PM +0100, Poul-Henning Kamp wrote: > Wouldn't it in fact make much more sense if revoke(2) was defined as > > int revoke(int fd); /* kick everybody else off */ > > and the code above would look like: An O_REVOKE flag to open might be neater? Dav