Erroneous parsing of command line arguments in trac-admin

[anonymous]

When adding permissions to an environment by means of the command line (rather than interactive mode), for example:

trac-admin C:\path\to\env permission add DOMAIN\user TRAC_ADMIN

The permission is added, but with a double backslash between the username and domain. The domain has to be specified because of the use of the Apache SSPI (mod_auth_sspi) module which gives us Windows Domain authentication, which we definitely need. This problem does not occur when going into interactive admin mode:

trac-admin C:\path\to\env

and then entering the permission add command:

permission add DOMAIN\user TRAC_ADMIN

This wouldn't be an issue if it weren't for the following: the interactive mode can't (AFAIK) be accessed from the command line, hence isn't accessible from a batch file. I use a batch file to create an environment and it would save loads of time if I could set the permissions correctly for each environment from that same batch file. I can imagine mine isn't the only scenario where this matters.

[anonymous]

I might add that this is probably a Windows-related issue (original submitter speaking here). The thing runs at my work under Windows 2003 Server (standard edition) SP2. I can't imagine that would be the only platform it wouldn't work on however.

Perhaps it's also a suggestion to include mod_auth_sspi as a recommendation in the installation instructions for Apache etc, because not only has it saved my ass from entering some 17 users manually with all their passwords (not all of which I even know) into a passwd file somewhere but I feel this module will work some real magic in any environment where everyone working with Trac and SVN is in the same Windows Domain (right about all software companies like mine, for example). I'd be more than willing to contribute some documentation on how to implement it, contact me at mels [@t] ml-webdesign [d0t] nl> or reply to this ticket (I check my mail more often than this ticket of course).

[anonymous]

Hi.

Just been fouled by this.

Try :

permission add DOMAIN\user

permission add "DOMAIN\user"

permission add 'DOMAIN\user'

permission add DOMAIN
user

Depending on your OS, shell and options one of this should work. Use

permission list
to verify what realy got to da DB. Thats what you should see on the
logged in

on top of the page.

[Christian Boos]

#7457 was closed as duplicate. #5334 is also related, but less closely as it doesn't talk about permissions but simply about '\' in paths.

The escaping has been added in r3513, but I think that's appropriate only for the interactive mode. On the command line, there shouldn't be such escaping, otherwise there's no way to specify only one backslash.

Please try out the following patch:

trac/admin/console.py

@@ -115 +115 @@
                 else:
                     encoding = locale.getpreferredencoding() # sys.argv
                 line = to_unicode(line, encoding)
-            line = line.replace('\\', '\\\\')
+            if self.interactive:
+                line = line.replace('\\', '\\\\')
             rv = cmd.Cmd.onecmd(self, line) or 0
         except SystemExit:
             raise

[Christian Boos]

Note that with the above, I can do either of:

$ # bash
$ trac-admin env add version \\
$ trac-admin env add version '\'
$ trac-admin env
[env]> add version \

and

> :: cmd.exe
> trac-admin env add version \
> trac-admin env
[env]> add version \

(from cmd.exe) with success, but nevertheless I get a failure for the corresponding unit-test, so I guess the test needs to be fixed somehow:

$ PYTHONPATH=. python25 trac/admin/tests/__init__.py
E.........................................................................
======================================================================
ERROR: test_backslash_use_ok (trac.admin.tests.console.TracadminTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Workspace\src\trac\repos\0.11-stable\trac\admin\tests\console.py", line 983, in test_backslash_use_ok
    self._execute('version add \\')
  File "C:\Workspace\src\trac\repos\0.11-stable\trac\admin\tests\console.py", line 119, in _execute
    retval = self._admin.onecmd(cmd)
  File "C:\Workspace\src\trac\repos\0.11-stable\trac\admin\console.py", line 120, in onecmd
    rv = cmd.Cmd.onecmd(self, line) or 0
  File "C:\Program Files\ActiveState\Python-2.5\lib\cmd.py", line 219, in onecmd
    return func(arg)
  File "C:\Workspace\src\trac\repos\0.11-stable\trac\admin\console.py", line 1087, in do_version
    arg = self.arg_tokenize(line)
  File "C:\Workspace\src\trac\repos\0.11-stable\trac\admin\console.py", line 203, in arg_tokenize
    for token in shlex.split(argstr.encode('utf-8'))] or ['']
  File "C:\Program Files\ActiveState\Python-2.5\lib\shlex.py", line 279, in split
    return list(lex)
  File "C:\Program Files\ActiveState\Python-2.5\lib\shlex.py", line 269, in next
    token = self.get_token()
  File "C:\Program Files\ActiveState\Python-2.5\lib\shlex.py", line 96, in get_token
    raw = self.read_token()
  File "C:\Program Files\ActiveState\Python-2.5\lib\shlex.py", line 191, in read_token
    raise ValueError, "No escaped character"
ValueError: No escaped character

----------------------------------------------------------------------
Ran 74 tests in 8.547s

FAILED (errors=1)

[Christian Boos]

Patch applied in r7393.

On the command line, there shouldn't be such escaping,

… because it's already done elsewhere in the code in this case (source:trunk/scripts/trac_admin.py@133#L572​).

Adjusting the unit-test and fixed other small issues in previous commits in r7394.

[Vineet Reynolds]

Replying to anonymous:

Hi.

Just been fouled by this.

Try :

permission add DOMAIN\user

permission add "DOMAIN\user"

permission add 'DOMAIN\user'

permission add DOMAIN
user

Depending on your OS, shell and options one of this should work. Use

permission list
to verify what realy got to da DB. Thats what you should see on the
logged in

on top of the page.

Just been bitten by the same issue in 0.10.4. Thanks for mentioning the workaround.