“Wojtek Lerch” <wojtek@qnx.com> wrote in message
news:94ta41$bqr$1@nntp.qnx.com…
Igor Kovalenko <> Igor.Kovalenko@motorola.com> > wrote:
Names don’t have meaningful
permissions mask even though they are filesystem objects. Anyone can
send
any message to anyone, including over network.
About this last point, I’m not agree with you, if you call the good
posix
function, or just use the default open() function in your resource
manager, if
you are talking about resource manager I don’t know about ‘QNX4 like’
names,
permission mask is evalutated.
Resource managers can check credentials when they handle open(). But
when you do name_open() does not. Not surprizingly, since when you do
name_attach() it creates name in filesystem space with bogus
permissions, without any respect to current umask.
Anyone can call raw ConnectAttach() and send any messages to anybody who
has a channel.
Which is bad. Channels are going to be associated with some filesystem
objects either way, whether it’s a resmgr or not (since clients need some
way to figure out the chid). It would make perfect sense to make permissions
mode be attribute of channels and use that mode when attaching a name into
filesystem space. Then ConnectAttach would not give you coid unless you have
sufficient credentials, no matter in what way you obtained chid, even if you
just guessed it. Think about Unix domain sockets, you can’t get a socket
unless your credentials are good. Think about SysV IPC which use same
approach for messages. Think about Mach IPC which also has built-in
security.
Such scheme would make the message passing inherently more secure and that’s
good if you’re really after security, isn’t it? Simpler resource managers
(serving single path) could also benefit from not having to check who the
client is for every message. The microkernel would get just marginally
bigger to handle that, but who gives a damn? After all rethorics in the
white papers all those ‘different memory models’ and ‘linking your app with
microkernel’ turned out to be just a smoke and we still can’t use
microkernel in pure form (untied from procnto).
The process that receives the message is free to check
the sender’s credentials and decide how to reply based on that. If
you’re using the resource manager library, the library does that check
for you; otherwise you still can do it in your own code – even if
you’re a resource manager that does resmgr_attach() but then calls raw
MsgReceive() and tries to handle all the io messages by hand…
The only real difference between a resource manager and names is that
since names are not required to support standard I/O messages they are
not required to support stuff like stat() or open() or any of the
other Posix permission checking. That’s their purpose – to let you
design your own messaging protocol that has nothing to do with the
standard Posix/QNX I/O messages. It’s up to you how you handle your
security concerns in your own protocol.
How ever you handle it in the protocol, you always have to check who the
sender is to make sure you aren’t being fooled. Library does that not by
magic but by spending your CPU cycles. Would not it be better to avoid the
very possibility of ever receiving a message from an unauthenticated guy?
