I'm working on the same project as Armando - we're setting up a savane
instance to support a US government research program about teams of
cognitively controlled software radios.
Actually, it is a feature. sv_users ignores unix accounts not
created by the backend on purpose, to avoid complications it may
implies (including security consideration).
That makes sense, but was baffling to me. I had a real account on the
box already, and then registered a savane account, using the same
name. This worked, and I was able to create projects. As far as I
can tell most things work except that I'm not in the group for the
project I created, so a cvs import operation failed.
I believe it's reasonable to want to have a real user match a savane
user, both because people have names they want to use all the time,
and because cvs is a bit awkward if you have to put usernames in the
CVSROOT.
>From my discussion with Armando about this I have the following
suggestions:
0) Declare invariants/rules that:
accounts on the box are in 3 categories
unix-only: primary gid != svusers, svusers is not in secondary gids
shell must not be the savane restricted shell.
must not be in any tables as a savane user, or project groups.
savane must never write to homedir or change anything.
savane-only: primary gid is svusers
shell must be the restricted shell.
normal savane user stuff.
savane-unix-both: primary gid != svusers, svusers in secondary gids
shell must not be the restricted shell.
savane must not write to home dir.
savane should perhaps not let the user register ssh keys
and instead say "[managed by real account]" or something like
that. Currently they seem to get registered and ignored.
So this implies, in order that all savane ops preserve the invariant:
Refuse to create an account if a Unix account is already present
unless the account is in the svusers group and the primary gid is
something else. Send an email to the unix account and the admins
with such failed attempts, pointing out that they should add
svusers as a secondary gid for the user if they wish to allow this.
--
Greg Troxel <[EMAIL PROTECTED]>
_______________________________________________
Savane-help mailing list
[email protected]
https://mail.gna.org/listinfo/savane-help
