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
* 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
>
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
< 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
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
< 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 manages to open a device that he owns anyway, it's his
problem if
> 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
> 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
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() ?
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:
--
> 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
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
I've been studying revoke(2), and somehow fail to see it fulfill
its promise from the man-page.
Consider this piece of code from init(8):
>/*
> * Start a session and allocate a controlling terminal.
> * Only called by children of init after forking.
> */
>
13 matches
Mail list logo
