:: Re: [Dng] vdev update and design do…
Top Page
Delete this message
Reply to this message
Author: Noel Torres
Date:  
To: dng
Subject: Re: [Dng] vdev update and design document
On Friday, 2 de January de 2015 19:43:04 Jude Nelson escribió:
> Hi Luke,
>
> I should point out, the ACL criteria for matching processes do not all have
> to be specified, specifically for the reason you point out. Using the
> SHA256 to match the process should be a tool of last resort, useful only
> when the executable's path, inode number, and PID listing commands are
> unreliable (for example, a program that runs from an arbitrary location but
> for which no PID listing program can be created). Also, taking the SHA256
> would be very slow compared to the other criteria. I'll update the design
> document to emphasize that vdev does not need all of the criteria to be
> set--just the ones that describe the class of processes the ACL affects.
>
> As much as I would like to revoke file descriptors, I'm afraid there's no
> way to do this that I know of without the kernel's help (but I'd love to
> learn of one). Systemd-logind has the same problem--once a process opens a
> file descriptor, another process can't force it to close it (i.e. with
> systemd-logind, the client can simply dup(2) the file descriptor before
> systemd-logind closes it). FreeBSD has revoke(2), but AFAIK there is no
> equivalent syscall for Linux.


Just a wild idea...

We could use /dev-real for the device nodes and /dev for named pipes pointing
to the device nodes. The named pipes can be connected or disconnected at will,
depending on the invoking process, while specialized programs (or root) could
just lurk around /dev-real if something needs to be debugged. This works for
reading and writing, but not for locking or ioctl, I know, but it is an
idea...

Just two (euro) cents

er Envite