lkml.org 
[lkml]   [2006]   [Jan]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)
Bodo Eggert <harvested.in.lkml@7eggert.dyndns.org> wrote:

> 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.

Because the architecture review commitee decided this would be the right way.

Note that we are on a migration from the classical root/non-root UNIX to a fine
grained privileges handling. The current documentation says that you need to
have a profile enabled shell as your SHELL in order to be able to use a
root-less Solaris.

> 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.

But you are right that another way would be to use something like "isaexec"

> > 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.

This is something that needs to be discussed. Last night, I found that there
should be a way to run cdrecord without the need to have the "file_dac_read"
provilege. I'll discuss this with the security group.



Jörg

--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni)
schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-
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 15:41    [W:0.043 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site