This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fwd: Re: cron and NT domains


On Fri, Jul 19, 2002 at 10:39:25AM +0200, Corinna Vinschen wrote:
> On Thu, Jul 18, 2002 at 10:39:40PM -0700, David MacMahon wrote:
> > I am getting these three errors: 1308, 1300, and 1326.
> 
> 1300: Not all privileges referenced are assigned to the caller.
> 
> That's bad.  It means, you're running cron probably not under
> SYSTEM account.  The error refers to:
> 
> The SeCreateTokenPrivilege is needed to do a NtCreateToken() call.
> Only SYSTEM has this privilege by default.

You're right, I was not running the program under the SYSTEM account
(although this thread is now talking about sshd, which is exhibiting the
same behvior as cron for me).  I was running sshd under a local user to
whom I had granted the priviliges listed in the documentation: "Act as
part of the operating system", "Replace process level token", and
"Increase quotas".  After reading your reply, I gave the local user the
"Create a token object" privilege.  That changed the 1300 error to 1326,
so I now get these errors when running under the local user account:
1308, 1326, and 1326.

When running sshd as SYSTEM, I get these errors: 1308, 5, 1326.  Error
5 is "Access Denied".  Here is the relevant excerpt from strace...

  195 16602933 [main] sshd 1968 setegid32: SetTokenInformation(process, TokenPrimaryGroup): Win32 error 1308
  114 16603047 [main] sshd 1968 seteuid32: uid: 6539 myself->gid: 10513
  145 16603192 [main] sshd 1968 seteuid32: Process token not verified
 1195 16604387 [main] sshd 1968 set_process_privilege: 0 = set_process_privilege (SeCreateTokenPrivilege, 1)
10019 16614406 [main] sshd 1968 extract_nt_dom_user: pw_gecos = 100B1512 (David MacMahon,U-ITSERVICES\DM2328,S-1-5-21-2057499049-1289676208-1959431660-203147)
12793 16614874 [select_pipe] sshd 2144 thread_pipe: stopping
  599 16615473 [main] sshd 2144 socket_cleanup: si 0x100CC9B0 si->thread 0x1A4
  130 16615603 [main] sshd 2144 socket_cleanup: connection to si->exitsock 0x1A8
 1156 16616759 [main] sshd 2144 socket_cleanup: returning
  169 16616928 [main] sshd 2144 peek_socket: considering handle 0x12C
  106 16617034 [main] sshd 2144 peek_socket: adding read fd_set /dev/tcp, fd 4
  103 16617137 [main] sshd 2144 peek_socket: adding write fd_set /dev/tcp, fd 4
  121 16617258 [main] sshd 2144 peek_socket: WINSOCK_SELECT returned 1
  101 16617359 [main] sshd 2144 set_bits: me 0x100B3A08, testing fd 4 (/dev/tcp)
  102 16617461 [main] sshd 2144 set_bits: ready 1
  115 16617576 [main] sshd 2144 select_stuff::poll: returning 1
   99 16617675 [main] sshd 2144 select_stuff::cleanup: calling cleanup routines
   96 16617771 [main] sshd 2144 select_stuff::~select_stuff: deleting select records
  365 16618136 [main] sshd 2144 set_process_mask: old mask = 0, new mask = 80000
   98 16618234 [main] sshd 2144 set_process_mask: old mask = 80000, new mask = 0
  111 16618345 [main] sshd 2144 _write: write (4, 0x100B5B08, 96)
   99 16618444 [main] sshd 2144 fhandler_socket::send: Fallback to winsock 1 send call
  302 16618746 [main] sshd 2144 _write: 96 = write (4, 0x100B5B08, 96)
 1016 16619762 [main] sshd 2144 cygwin_select: 10, 0x100B3948, 0x100B43A0, 0x0, 0x0
  271 16620033 [main] sshd 2144 dtable::select_read: /dev/piper fd 3
  187 16620220 [main] sshd 2144 dtable::select_read: /dev/tcp fd 4
  647 16620867 [main] sshd 2144 dtable::select_read: /dev/ptym fd 9
  145 16621012 [main] sshd 2144 cygwin_select: to NULL, ms FFFFFFFF
   98 16621110 [main] sshd 2144 cygwin_select: sel.always_ready 0
  518 16621628 [main] sshd 2144 start_thread_socket: Handle 0x12C
  113 16621741 [main] sshd 2144 start_thread_socket: Added to readfds
  377 16622118 [main] sshd 2144 start_thread_socket: exitsock 0x1A8
  123 16622241 [main] sshd 2144 start_thread_socket: stuff_start 0x22F30C
  207 16622448 [main] sshd 2144 select_stuff::wait: m 3, ms 4294967295
  497 16622945 [select_socket] sshd 2144 thread_socket: stuff_start 0x100CF9D4
521384 17135790 [main] sshd 1968 seterrno_from_win_error: /netrel/src/cygwin-1.3.12-2/winsup/cygwin/security.cc:297 windows error 5
  203 17135993 [main] sshd 1968 geterrno_from_win_error: windows error 5 == errno 13
  776 17136769 [main] sshd 1968 set_process_privilege: 1 = set_process_privilege (SeCreateTokenPrivilege, 0)
  486 17137255 [main] sshd 1968 create_token: -1 = create_token ()
  212 17137467 [main] sshd 1968 seteuid32: create token failed, try subauthentication.
 1004 17138471 [main] sshd 1968 set_process_privilege: 0 = set_process_privilege (SeTcbPrivilege, 1)
 1077 17139548 [main] sshd 1968 extract_nt_dom_user: pw_gecos = 100B1512 (David MacMahon,U-ITSERVICES\DM2328,S-1-5-21-2057499049-1289676208-1959431660-203147)
116361 17255909 [main] sshd 1968 subauth: LsaLogonUser: -1073741715
  224 17256133 [main] sshd 1968 seterrno_from_win_error: /netrel/src/cygwin-1.3.12-2/winsup/cygwin/security.cc:969 windows error 1326
  110 17256243 [main] sshd 1968 geterrno_from_win_error: unknown windows error 1326, setting errno to 13
 1201 17257444 [main] sshd 1968 set_process_privilege: 0 = set_process_privilege (SeTcbPrivilege, 0)
  194 17257638 [main] sshd 1968 setuid32: real: 18, effective: 18

The error code 5 reminded me of my mkpasswd problem, but it turns out
my mkpasswd problem was due to user error.  I *can* do "mkpasswd -d -u
<username> <domain>".  What I trying before ("mkpasswd -d <domain> -u
<username>") was incorrect syntax.

One interesting thing, however, is that mkpasswd doesn't handle RIDs >
65535 too well...

DM2328:unused_by_nt/2000/xp:213147:10513:DM2328,U-DOMAIN\DM2328,S-1-5-21-DDD
-203147://NTSRV/DM2328$:/bin/bash

With this passwd entry, the uid gets set to 16539, which is (213147 %
0x10000L), but there is no uid-to-username mapping for uid 16539 so
things like 'id' and 'ls -l' show only the numeric value for uid (i.e.
16539).  IMHO, until uids are 32 bits, mkpasswd should be changed to use
((RID+offset) % 0x10000L) as the uid.  It will (still) have conflicts if
two users' RIDs differ by a multiple of 65536, but that conflict exists
with the current mkpasswd (it's just not so apparent).

It would also be nice if mkpasswd could detect the incorrect (though
intuituve, IMHO) syntax that I had been using and print a more
meaningful error message.

Thanks again,
Dave

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]