"David W. Chapman Jr." wrote: > > Why is this actually necessary for SAMBA? > > > > Is it necessary for all three of these to permit this, or is > > it sufficient to (for example) allow it in the group name? > > > > Samba needs a user account for the domain "machine account" > > the machine account always ends with a $ > > So it would only have to be for the account name
I gathered that from the SAMBA site, too. The '$' is a pain. None of the examples in the original post would have worked, because the '$' was not '\$', and the shell would have blown chunks over the "variable expansion". It seems to me that this could cause a great deal of problems for scripts that process the password files, as they currently exist, if they use constructs like "eval", or back-ticks, etc.. If it's allowed, it whould probably only be allowed in the user name (i.e. the patch is wrong; it should probably add another parameter to the allowable values of 'int gecos', and change it to 'int checktype' or similar). It seems to me that another alternative is that all these names end in '$'; therefore, when you are expecting one of these names, you could imply a '$', without needing to actually have it in the password file -- in other words, it's an attribute, not really part of the account name. Will this open up a security hole for a nomal user account being used to compromise the domain system security? Is it absolutely necessary to use an in-band method to distinguish these records from ordinary user accounts? If the answer to either of these is "no", then it seems that implying the '$', rather than permitting it directly, would be best, to keep scripts working. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
