Quoting Andrew Morgan ([EMAIL PROTECTED]):
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> [I've droped lkml]
>
> KaiGai Kohei wrote:
> >> But !cap_xxx is a bit misunderstandable for me. Someone may misunderstand
> >> this line means any capabilities except for cap_xxx.
>
> I like '!', but you're going to code it... ;-) I can live with b:.
>
> >> Thus, I think that using "b:" and omittable "i:" prefix is better than "!".
> >> In addition, what is your opinion about using "-b:" and "-i:" to represent
> >> dropping capabilities currently they have?
>
> I'd prefer something simple:
>
> i: set inheritable exactly (don't retain any other than these)
> b: drop exactly these (leave the others untouched)
Simple is good, especially for something like this.
It'd also be very nice to have a little wrapper test program like
test_pamcap serge
which simply reports the resulting inheritable and cap_bound sets.
Maybe that already exists. But so long as I can do
for u in `cat /etc/passwd | awk -F: '{ print $2 '}`; do
test_pamcap $u
done
where test_pamcap uses the exact same library function to parese the
configuration file as used by the pam module.
> >> There is one more uncertain case.
> >> When a user belongs to several groups with capabilities configuration,
> >> what capabilities are to be attached for the user?
> >
> >> e.g) When kaigai belong to @pingers and @paccters
> >
> >> b:cap_sys_pacct @paccters
> >> b:cap_net_raw @pingers
> >> -b:cap_dac_override,cap_net_raw kaigai
>
> The pam_cap module currently just accepts the first valid 'i:'(sic)
> entry for the user. Since groups are not supported, this made sense.
> With support for groups, I can see a compelling case for "OR". So, if
> you want to support an "OR" policy, I say go for it.
Agreed.
This sounds great, guys!
thanks,
-serge
-
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
