lkml.org 
[lkml]   [2006]   [Jan]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)
Date
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/

\
 
 \ /
  Last update: 2006-01-24 10:10    [W:0.615 / U:1.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site