--t0UkRYy7tHLRMCai
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 02, 2005 at 05:23:21PM +0100, Steinar Hamre wrote:
> der Mouse <mouse@Rodents.Montreal.QC.CA> writes:
>=20
> > > [...stuff about Solaris calls that use an fd as a handle on a
> > > directory...]
> >=20
> > How do they deal with the x-only directory problem (you can't open() it
> > but there's no reason you shouldn't be able to use it with calls like
> > these)?  I've often wanted to be able to open . and then use the fd,
> > usually for fchdir(), but potentially for these.  Does Solaris have an
> > O_NOACCESS or something to deal with that?
>=20
> Doesn't seem like they have a solution to that.  Can I suggest
> O_WRONLY+O_RDWR?

No. You may not. The read & write flags were done weirdly and I don't=20
think we should further propogate those bitfields around.

> (O_RDONLY+O_WRONLY=3DO_RDWR would be more natural, but it's way too late
> for that.  Hmm... I don't want to think about how much code there is
> that depends on O_RDONLY=3D0)

The kernel versions of these flags actually work that way. Which is why I=
=20
strongly dislike your suggestion above. :-)

> I'm a bit unsure how this should work for other file types.  ioctls
> might be an issue from top of the bag of stuff done with fds that is
> neither writing nor reading.  Could O_NOACCESS open up any bad ioctls
> not available before?  What about a system call to do exec on the fd
> of a regular executable file? O_EXEC?

To be honest, I think we should avoid O_NOACCESS until we figure out all=20
its semantics.

Take care,

Bill

--t0UkRYy7tHLRMCai
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFCJfNLWz+3JHUci9cRAucjAKCKlFjYbohvoquuaXVYhRNWRaSKXACfVkom
IaiD4XODw4BMwDKXTOBW0B0=
=5HIJ
-----END PGP SIGNATURE-----

--t0UkRYy7tHLRMCai--