Daniel J Walsh wrote:
On 06/30/2009 11:18 AM, Joshua Brindle wrote:
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.
I am not sure what is going on here, since it should never match on root
: or root:
This should be falling through to the default user of the
/etc/selinux/targeted/seusers file. Since you did not specify a valid
"service" name.
The interface is looking for something that looks like:
*:staff_u:s0
or
sshd:guest_u:s0
login:staff_u:so-s0:c0-c1023
xdm:user_u:so
I don not currently intend this to be edited by a human, the goal was to
allow tools like IPA or other scripting tools to populate these files.
The library should return the content as it does, but libselinux or
pam_selinux should deny login if the machine is in enforcing mode. The
fact that it is giving you a bogus login is a bug in current SELinux.
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.
Patch merged in libselinux 2.0.84.
--
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.
