Jim/Darren:
I think that perhaps I did not make my concern very clear. According to
the getuserattr and user_attr manpages, they seem to imply that the
C-functions are the supported way to access this file:
Programs use the getuserattr(3SECDB) routines to gain access
to this information.
[...]
The command-line syntax is Committed. The output is Uncom-
mitted.
The manpage isn't too clear about the stability of the user_attr
file format, but I get the impression that it is not declared a stable
interface. So, I suspect that we way need a contract to parse the file
directly. Have you or Jim talked with the security team (e.g. Gary
Winiger) to find out if a contract is needed? If not, then we should.
If a contract is needed to parse the file directly, then using the
getuserattr or setuserattr functions may be less of a hassle, even
though it would require shipping an extra small binary. But we could
also go the contract route if we wanted, and if it is acceptable to
the supplier.
Also would probably be good to talk to the security team about the
fact that it would be handy to have perl and perhaps python bindings
for these RBAC access functions, so that they can be parsed from
such programs without having to parse the user_attr file directly.
Brian
> I think that what Jim has done is more than sufficient for 2009.06, but I do
> agree we need a better solution since it's looking like Users& Groups is
> taking
> on a life of it's own - it was expected that all the GST tools were a
> short-term
> solution until Visual Panels integrated, but it's looking like user admin
> isn't
> happening soon.
>
> For a longer term solution, I believe that we shouldn't be writing a new C
> program - we should be using a perl binding to libsecdb to allow us to call
> this
> function from perl - this could also be a private i/f if necessary.
>
> (I've an example below that works for me )
>
> Darren.
>
> ---- Attempt to generate a binding ---
>
> I tried this out on snv_112, and I was able to fairly easily generate a
> binding
> for getuserattr() with SWIG (/bin/swig):
>
> 1) Create interface file - user_attr.i - containing:
>
> %module user_attr
> %{
> #include "secdb.h"
> #include "user_attr.h"
> %}
>
> %include "secdb.h"
> %include "user_attr.h"
>
> 2) Generate perl bindings:
>
> $ swig -I/usr/include -perl5 user_attr.i
>
> 3) Compile and Link to a .so:
>
> $ cc -c user_attr_wrap.c `perl -MExtUtils::Embed -e ccopts`
> $ ld -G user_attr_wrap.o -o user_attr.so -lsecdb
>
> 4) Use it:
>
> use user_attr;
>
> $uattr = user_attr::getusernam( "root" );
> printf( "Name: %s\n", $uattr->{name});
> printf( "Attr: length = %d\n", $uattr->{attr}->{length});
> printf( "Attr: %s = %s\n", "roles",
> user_attr::kva_match($uattr->{attr}, "roles" ) );
> printf( "Attr: %s = %s\n", profiles,
> user_attr::kva_match($uattr->{attr}, "profiles" ) );
> printf( "\n" );
>
>
> Which output:
>
> Name: root
> Attr: length = 5
> Attr: roles =
> Attr: profiles = Web Console Management,All
>
> ---------
>
>
>
> On 29/04/2009 19:42, Brian Cameron wrote:
>> Jim:
>>
>> There is a C-interface called getuserattr(3SECDB) which allows you
>> to easily access user_attr values. Wouldn't it be better to use this
>> rather than try to parse the file directly?
>>
>> Perhaps it would be good to write a small C-program to get the data
>> you need and use it to get the data you need?
>>
>> Brian
>>
>>
>>> The backend cann't get the correct user's profiles, cause 'profiles
>>> $name' command has change it's format of output. This patch get an
>>> user's profiles by directly parsing /etc/user_attr file instead of using
>>> profiles command.
>>>
>>> thanks
>>>
>>> Jim
