On Mon, 5 Aug 2002 21:21, Richard Gooch wrote:
> Ug! Unstructured binary data. No way.
Can you suggest a better idea? Maybe just using an unsigned int for any
extension?
> Didn't you read the "device name MUST come last" comment?
Yes, but making it remain at the end means totally breaking binary
compatability.
> It's a horrible interface for many reasons.
Got a better suggestion?
> > What I want to do is have my SE Linux devfsd module know the
> > security context (expressed as an unsigned int) of the process that
> > is accessing a device node. Alternate solutions to this problem are
> > welcome.
>
> Why not just have the PID reported, then you can look up its security
> context? Whether you send the PID or the security context, you have
> the problem that the identifier you send can become invalid by the
> time devfsd gets around to processing it. This is why I never added
> the PID in the first place. If the identifier becomes recycled, nasty
> exploits could be written.
For what I want to do it's OK to operate on the old security ID in the case
where a process changes security context (through exec). So if I get the SID
then it's OK if the SID changes. The PID is more problemmatic because if the
process ends and it's entry in the process table gets replaced by an
unrelated process then it could potentially be a problem.
--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
>From field.
|