Daniel J Walsh wrote:
On 06/19/2009 11:08 AM, Joshua Brindle wrote:
Daniel J Walsh wrote:
On 06/18/2009 04:14 PM, Joshua Brindle wrote:
Daniel J Walsh wrote:
On 06/18/2009 09:48 AM, Joshua Brindle wrote:
Joshua Brindle wrote:
Daniel J Walsh wrote:
The idea here is to break the seusers file up into lots of little
seusers file that can be user specific, also adds the service
field to
be used by tools like pam_selinux to choose which is the correct
context
to log a user in as.
Patch was added to facilitate IPA handing out SELinux content for
selection of roles at login.
This patch does not affect the behavior of getseuserbyname(), how is
this expected to work with existing applications?
I think it only affects pam_selinux.
The function name is very confusing if its only used for pam_selinux,
I'd like it renamed but seeing that pam_selinux is already deployed
with
it I suppose that isn't an option.
Signed-off-by: Joshua Brindle <method@xxxxxxxxxxxxxxx>
Also, what is the format of this file? What should service be to test
this on F11?
It is not only for pam_selinux, but that is currently the only user.
Really all this function does is add a second variable when selecting a
users default context. service is just a string that the caller can
specify. It just allows you to change the default context you would get
on entry to the system. So I guess you could get use similar calls to
get different context depending on whether or not you are on the
console. Imagine a dbus service which would run with one context if you
we logged onto the console versus a different context if you were logged
in via ssh.
On looking at this further, I don't like the format of the file either,
why did you choose to make it use colons and not tolerate spaces? First
when I tried root: staff_u: s0 it logged me in as system_u and then when
I tried root:staff_u:s0 I got logged in correctly. This is a little
fragile to expect editing by users and getting unexpectedly logged in as
system_u.
--
The : separated list matches seusers and /etc/passwd so I think it makes
sense. THe file should require all three fields, that is a bug.
Ok, This is also yet-another-way to map users in SELinux, and its different from
everything else. We use contexts to map other services to users ala
contexts/default_contexts and contexts/users/*. Why should this be any
different? If there are multiple sshd's running, eg., on a high nic and low nic
then they'd need to map contexts via context rather than "service" name.
I still haven't figured out what this is solving.
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
