Ticket History #795: OSF/1 5.0 revoke fails

From tschroed@ml.media.mit.edu Thu Feb 10 17:43:35 2000
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2])
by rt-11.mit.edu (8.9.3/8.9.3) with SMTP id RAA14587
for <bugs@RT-11.MIT.EDU>; Thu, 10 Feb 2000 17:43:35 -0500 (EST)
Received: from ml.media.mit.edu by MIT.EDU with SMTP
id AA20921; Thu, 10 Feb 00 17:43:33 EST
Received: from localhost (tschroed@localhost)
by ml.media.mit.edu (8.8.8/8.8.7) with ESMTP id RAA16069
for <krb5-bugs@mit.edu>; Thu, 10 Feb 2000 17:43:34 -0500 (EST)
Message-Id: <Pine.OSF.4.05.10002101736360.10819-100000@ml.media.mit.edu>
Date: Thu, 10 Feb 2000 17:43:33 -0500 (EST)
From: Trevor Schroeder <tschroed@media.mit.edu>
To: krb5-bugs@MIT.EDU
Subject: OSF/1 5.0 revoke fails

I looked through documentation and mailing lists, but I didn't find this
anywhere.

In order to get Kerberos5 working on Tru64 / Digital UNIX / OSF/1 5.0,
it's necessary to change the semantics of the revoke(2) system call.
Otherwise open_pty_slave fails to revoke(). Tack

vfs:
revoke_tty_only=0

on to the end of /etc/sysconfigtab (for future system boots) and execute
the command (for the currently running system):

sysconfig -r vfs revoke_tty_only=0

If this is already documented, my apologies. (and could you tell me
where so that I'll be sure to check there in the future :)


Responsible-Changed-From-To: gnats-admin->krb5-unassigned
Responsible-Changed-By: raeburn
Responsible-Changed-When: Tue Feb 22 16:33:03 2000
Responsible-Changed-Why:

Reformat, fix category.

Responsible-Changed-From-To: krb5-unassigned->tlyu
Responsible-Changed-By: tlyu
Responsible-Changed-When: Wed Jan 24 17:53:59 2001
Responsible-Changed-Why:

refile

State-Changed-From-To: open-analyzed
State-Changed-By: tlyu
State-Changed-When: Wed Jan 24 17:54:12 2001
State-Changed-Why:

known problem; investigating


From: Tom Yu <tlyu@MIT.EDU>
To: Trevor Schroeder <tschroed@media.mit.edu>
Cc: krb5-bugs@MIT.EDU
Subject: Re: pty/822: OSF/1 5.0 revoke fails
Date: 24 Jan 2001 18:05:18 -0500





Do you actually know any further details about this problem? It
smells like an OS bug... The point in the code that is calling
revoke() does so after closing the slave device received from
openpty() or equivalent. revoke() returning ENOTTY is probably a bug,
but some experimentation reveals that calling revoke() on a slave pty
file descriptor without closing it first doesn't result in ENOTTY.
It's possible that there's some bug involving various STREAMS modules
not being pushed on open of the slave pty device after it's been
closed, but if that were the case, other pty-related stuff should
fail, right?

---Tom

From: Trevor Schroeder <tschroed@media.mit.edu>
To: Tom Yu <tlyu@MIT.EDU>
Cc: krb5-bugs@MIT.EDU
Subject: Re: pty/822: OSF/1 5.0 revoke fails
Date: Wed, 24 Jan 2001 18:19:43 -0500

On Wed, Jan 24, 2001 at 06:05:18PM -0500, Tom Yu wrote:


sys_attrs_vfs(5) says:

* revoke_tty_only
A value that determines whether the revoke() system call can invalidate
file descriptors on block special devices. If revoke_tty_only is set to
1 (the default), the revoke() argument must be a character (tty) dev-
ice, and a block device argument results in an [ENOTTY] error. If
revoke_tty_only is set to 0, the revoke() argument can be either a
character or a block device.

Default value: 1 (character devices only)

You can modify this attribute at run time; however, the default value
is strongly recommended in a TruCluster environment.



In retrospect, it does seem weird that it fails on what should be a
character device. What's the path it's trying revoke? I haven't actually
looked. :)

As a general rule, I'm willing to ascribe lots of bad behavior to STREAMS
as most STREAMS code seems to be at least partially broken in very
significant ways.

State-Changed-From-To: analyzed-closed
State-Changed-By: tlyu
State-Changed-When: Fri Aug 16 17:21:18 2002
State-Changed-Why:

Fixed in 1.2.3.