Bug 25961
| Summary: | [MFC] rmuser is not case sensitive | ||
|---|---|---|---|
| Product: | Base System | Reporter: | dan <dan> |
| Component: | bin | Assignee: | Doug Barton <dougb> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | Unspecified | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
dan
2001-03-21 09:13:25 UTC
rmuser is not case sensitive. It will confirm the user you wish to delete, but then it deletes more than one user. Fix: Linh Pham <lplist@closedsrc.org> reported this in response to my post in -questions (200103192332.f2JNWXb68437@ns1.unixathome.org): In the rmuser script, there is a Search/Replace call that has /io, which searches in non-case sensitive mode. Below is a clip of what I have under 4.2-STABLE: while (<MASTER_PW>) { if (not /^\Q$login_name:/io) { print NEW_PW; } else { print STDERR "Dropped entry for $login_name\n" if \ $debug; $skipped = 1; } } Removing the i would probably resolve the non-case sensitive issue of rmuser. How-To-Repeat: adduser JOHN, adduser john, them rmuser john, both users are removed. I just wanted to clarify my post to -questions:
There is a line in the rmuser script that has:
if (not /^\Q$login_name:/io) {
which should be
if (not /^\Q$login_name:/o) {
since /io does the search in a case-insensitive manner and scans through
the variable only once. /o would make the search case-sensitive... as it
should.
Sorry if this wasn't really clear in my original post.
--
Linh Pham
[lplist@closedsrc.org]
// 404b - Brain not found
On 11 Apr 2001, at 15:12, Linh Pham wrote: > I just wanted to clarify my post to -questions: > > There is a line in the rmuser script that has: > > if (not /^\Q$login_name:/io) { > > which should be > > if (not /^\Q$login_name:/o) { > > since /io does the search in a case-insensitive manner and scans through > the variable only once. /o would make the search case-sensitive... as it > should. > > Sorry if this wasn't really clear in my original post. What you've written above makes sense to me. Thank you. -- Dan Langille pgpkey - finger dan@unixathome.org | http://unixathome.org/finger.php got any work? I'm looking for some. State Changed From-To: open->feedback What benefit is obtained from having two users on the system with the same username, differing only by case? Even if it was a benefit of some sort, it would likely cause all kinds of other problems. Responsible Changed From-To: freebsd-bugs->dougb I am familiar with the code in question On 14 Apr 2001, at 18:46, dougb@FreeBSD.org wrote: > Synopsis: rmuser is not case sensitive > > State-Changed-From-To: open->feedback > State-Changed-By: dougb > State-Changed-When: Sat Apr 14 18:44:45 PDT 2001 > State-Changed-Why: > > What benefit is obtained from having two users on the system with the > same username, differing only by case? Even if it was a benefit of > some sort, it would likely cause all kinds of other problems. The point of the PR is not to make it easier to have two users. The point of the PR is to remove the unexpected behaviour in the case where you DO have two users. I'm not setting administrative policy, which is beyond the scope of this PR (i.e. tools not policy). The script asks you if you want to remove a particular user (i.e. the one you specified). You confirm. Then the script removes both users. This violates POLA. I think the script is case sensitive for the confirmation but case insensitive for the delete. For consistency, it should use one or the other, but not both. I think case sensitive makes the most sense. If you do wind up with two users with the same name, different case, then at least rmuser can be used to remove the one you don't want. -- Dan Langille pgpkey - finger dan@unixathome.org | http://unixathome.org/finger.php got any work? I'm looking for some. State Changed From-To: feedback->closed Installations that have two users with the same characters capitalized differently should not be using the standard tools, since their situation is highly non-standard, and likely to break things. Given that it's hard to place POLA on one side or the other of this argument, let's err on the side that is most likely to produce working systems for the majority of users. Would someone please reopen this PR? I don't think we're quite finished with the feedback yet. On 15 Apr 2001, at 12:25, dougb@FreeBSD.org wrote: > Synopsis: rmuser is not case sensitive > > State-Changed-From-To: feedback->closed *sigh* > State-Changed-By: dougb > State-Changed-When: Sun Apr 15 12:23:01 PDT 2001 > State-Changed-Why: > > Installations that have two users with the same characters capitalized > differently should not be using the standard tools, since their situation > is highly non-standard, and likely to break things. You have completely missed my points. I am not saying that we should cater for such installations. I'm talking about a situation where two where two users with the same characters have been created, perhaps by accident. Then they go to delete one. But rmuser deletes both. > Given that it's hard to > place POLA on one side or the other of this argument, It's not hard to place POLA at all. Look at rmuser alone. In one section of remuser, it is case sensitive ("is this the user do you wish to delete?". In another, it's case insensitive ("OK, I'll delete both users now"). This is a bug. Plain and simple. It asks if you to delete steve. And it deletes both Steve and steve. That's not right. > let's err on the side > that is most likely to produce working systems for the majority of users. How is fixing this bug going to break anything? -- Dan Langille pgpkey - finger dan@unixathome.org | http://unixathome.org/finger.php got any work? I'm looking for some. I agree with Dan here, rmuser breaks POLA by being inconsistent. In message <200104151946.f3FJkme33474@ns1.unixathome.org>, "Dan Langille" write s: >Would someone please reopen this PR? I don't think we're quite >finished with the feedback yet. > >On 15 Apr 2001, at 12:25, dougb@FreeBSD.org wrote: > >> Synopsis: rmuser is not case sensitive >> >> State-Changed-From-To: feedback->closed > >*sigh* > >> State-Changed-By: dougb >> State-Changed-When: Sun Apr 15 12:23:01 PDT 2001 >> State-Changed-Why: >> >> Installations that have two users with the same characters capitalized >> differently should not be using the standard tools, since their situation >> is highly non-standard, and likely to break things. > >You have completely missed my points. I am not saying that we should >cater for such installations. I'm talking about a situation where two >where two users with the same characters have been created, perhaps >by accident. Then they go to delete one. But rmuser deletes both. > >> Given that it's hard to >> place POLA on one side or the other of this argument, > >It's not hard to place POLA at all. Look at rmuser alone. In one section >of remuser, it is case sensitive ("is this the user do you wish to >delete?". In another, it's case insensitive ("OK, I'll delete both users >now"). This is a bug. Plain and simple. It asks if you to delete steve. >And it deletes both Steve and steve. That's not right. > >> let's err on the side >> that is most likely to produce working systems for the majority of users. > >How is fixing this bug going to break anything? > >-- >Dan Langille >pgpkey - finger dan@unixathome.org | http://unixathome.org/finger.php >got any work? I'm looking for some. > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-bugs" in the body of the message > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. State Changed From-To: closed->analyzed There is disagreement as to the right thing to do Responsible Changed From-To: dougb->phk phk volunteered to head this up by virtue of comments from the peanut gallery Responsible Changed From-To: phk->alfred Because this wasn't all the much of a big deal in the first place. State Changed From-To: analyzed->closed fixed. Geez! Dan Langille wrote:
> You have completely missed my points.
Don't make the mistake of thinking that becuase I don't agree with you I
couldn't possibly have understood what you said. I do understand exactly
what you're saying, and I think that you are wrong. However, the mass of
public opinion is on the side of maintaining case sensitivity. Go figure.
State Changed From-To: closed->analyzed I committed a better fix, and will MFC it after the freeze. Responsible Changed From-To: alfred->dougb There was a time, not too long ago, when people on this project knew how to take a joke. On 15 Apr 2001, at 13:04, Doug Barton wrote: > Dan Langille wrote: > > > You have completely missed my points. > > Don't make the mistake of thinking that becuase I don't agree with you I > couldn't possibly have understood what you said. I do understand exactly > what you're saying, and I think that you are wrong. That's not why I thought you didn't understand. > However, the mass of > public opinion is on the side of maintaining case sensitivity. Go figure. Don't get me wrong. I don't create mixed case users. I inherited a system such a system. I removed one. I lost two. cheers. -- Dan Langille pgpkey - finger dan@unixathome.org | http://unixathome.org/finger.php got any work? I'm looking for some. State Changed From-To: analyzed->closed Fix MFC'ed. |
