Russell Coker writes:
> The .devfsd interface doesn't allow any extensions to the interface. If the
> devfsd_notify_struct was changed to the following:
>
> struct devfsd_extension
> {
> unsigned int ext_type; /* type of the extension */
> unsigned int len; /* length of this extension packet including this
> field and the ext_type field */
> /* other data goes here */
> };
Ug! Unstructured binary data. No way.
> struct devfsd_notify_struct
> { /* Use native C types to ensure same types in kernel and user space */
> unsigned int type; /* DEVFSD_NOTIFY_* value */
> unsigned int mode; /* Mode of the inode or device entry */
> unsigned int major; /* Major number of device entry */
> unsigned int minor; /* Minor number of device entry */
> unsigned int uid; /* Uid of process, inode or device entry */
> unsigned int gid; /* Gid of process, inode or device entry */
> unsigned int overrun_count; /* Number of lost events */
> unsigned int namelen; /* Number of characters not including '\0' */
> /* The device name MUST come last */
> char devname[DEVFS_PATHLEN]; /* This will be '\0' terminated */
> unsigned int extlen; /* Number of characters in extension fields */
> /* devfsd_extension data */
> };
Didn't you read the "device name MUST come last" comment?
> With this the main devfsd doesn't need to be modified and can just
> ignore the extra data. Any modules that need extra data can look
> through the extension list for anything that they know about, the
> rest can ignore it.
It's a horrible interface for many reasons.
> 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.
Regards,
Richard....
Permanent: rgooch@xxxxxxxxxxxxx
Current: rgooch@xxxxxxxxxxxxxxx
|