Messages in this thread | | | From | Bodo Eggert <> | Subject | Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?) | Date | Tue, 24 Jan 2006 10:14:39 +0100 |
| |
Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
[...] > On Solaris, you (currently) use a profile enabled shell (pfsh, pfksh or pfcsh) > that calls getexecuser() in order to find whether there is a specific > treatment needed. If this specific treatment is needed, then the shell calls > execve(/usr/bin/pfexec cmd <args>) > else it calls execve(cmd <args>) > > I did recently voted to require all shells to be profile enabled by default.
Why? I asume there will only be few programs requiring to be run by a wrapper, and mv /usr/bin/foo to /usr/pfexec-bin/foo; echo $'#!/bin/sh\n/usr/sbin/pfexec /usr/pfexec-bin/foo "$@"' > /usr/bin/foo; chmod 755 /usr/bin/foo should be easier than patching e.g. all callers of cdrecord, and it won't slow down starting non-profiled applications.
Possibly the pfexec can tell the application to be run by the basename (like su1), in this case you'd add something like "alias cdrecord /opt/schily/bin/cdrecord" to it's configuration and link it to /usr/bin/cdrecord.
> With the future plans for extending fine grained privs on Solaris, sending > SCSI commands will become more than one priv. > > I proposed to have a low priv right to send commands like inquiry and test > unit ready. These commands may e.g. be send without interfering a concurrent > CD/DVD write operation. > > The next priv could be the permission for sending simple SCSI commands that > allow reading from the device. > > The next priv could be the permission for sending simple SCSI Commands that > allow writing. > > The final priv would allow even vendor specific commands: this is what > cdrecord needs.
That sounds reasonable, but I wonder how you can get access to a device file descriptor in order to do unprivileged access. -- Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF verbreiteten Lügen zu sabotieren. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |