[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Local group and ldap user combination
On Thu, 14 Mar 2013, Gerhardus Geldenhuis wrote:
Just to clarify how I am testing: If my user is part of the adm user in
Ubuntu it can less log files if not then it can't less log files. Adding
myself to an ldap based adm group gives me the abillity to access the
log files but as said above this does not seem to correlate with what
nsswitch is configured to do.
I don't know if this is your actual use case, but a classic trick for file
access is to make multiple groups:
adm:*:4:foo
adm2:*:4:bar
with the same gid. Then you'll initgroups() the proper gid (regardless of
if you're in adm or adm2) and the kernel should let you less log files or
whatever. In your environment, you might consider it safe to even have adm
on disk and adm2 in LDAP.
Things can get less clear for userspace programs that might do a
getgrnam() or similar, of course...and for sysadmins thereof.
Just a little bit of follow up,I would have preferred to do all user and
group management in ldap. We are reluctant to get rid of the adm group
because of reliance on it from other services. In the case
authentication failure (ldap) it would mean the server can still
function without any problem. We can use puppet to configure group
members of adm but that fractionates user management.
If your main concern is (potentially) offline access to LDAP this has been
approached dozens of times at every possible layer. As an example of doing
this on the OpenLDAP side, a local slapd(8) fed with syncrepl providing
nssov can gracefully resync as network is available and still function
fully when detached (for example, on a laptop or other poorly connected
site). There are options at other layers (e.g. offline-aware nss
providers) as well.