Bug 3648 - Result value in automount_lookup is not correctly trimed
Summary: Result value in automount_lookup is not correctly trimed
Status: NEW
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: User/Group Accounts (show other bugs)
Version: 3.0.21c
Hardware: SGI IRIX
: P3 normal
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
: 3730 (view as bug list)
Depends on:
Reported: 2006-03-31 01:24 UTC by Maik Hertha
Modified: 2006-06-22 15:00 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Maik Hertha 2006-03-31 01:24:35 UTC
I hope this problem is not only Irix specific.
The nis-lookup for an entry in auto.home-map has a trailing newline. This was stripped in samba releases before 3.0.2x.
Starting with samba 3.0.20 this behavior changed to NOT stripping the trailing newline after the nis-lookup. So I tracked the problem to the automoun_lookup function in source/lib/util.c.

In samba-3.0.14a the function automount_lookup (source/lib/util.c - NOT nisplus) the end of the string is marked with '\0'. This leads to the correct result.

-- 3.0.14a

strncpy(last_value, nis_result, nis_result_len);
last_value[nis_result_len] = '\0';

-- end

Starting with the 3.0.2x series the code changed to:

-- 3.0.2x

fstrcpy(last_key, user_name);
pstrcpy(last_value, nis_result);

-- end

Unfortunatly the trailing newline from the nis-lookup was no longer stripped.
The log results in:

[2006/03/31 08:54:51, 0] smbd/service.c:(660)
  '/usr2/people/hertha_' does not exist or permission denied when connecting to [hertha] Error was No such file or directory

-- log.

The real result should be /usr2/people/hertha, so the newline changes to underscore.

Changing the code to:

fstrcpy(last_key, user_name);
pstrcpy(last_value, nis_result);

--> last_value[nis_result_len] = '\0';


-- end.

The result will be correct an the connection is successful.

I don't know if this is a patch or more a hack ;-). I found no trim function, that would the correct solution.

Comment 1 Gerald (Jerry) Carter 2006-04-20 08:03:41 UTC
severity should be determined by the developers and not the reporter.
Comment 2 Gerald (Jerry) Carter 2006-06-22 15:00:30 UTC
*** Bug 3730 has been marked as a duplicate of this bug. ***