Hi! On 13.11.2010 05:39, Charles Wilson wrote: > On 11/12/2010 10:49 AM, Gernot Hillier wrote: >> The only strange thing I stumbled over was that my Windows XP 64bit was >> classified as NT 5.2 by uname, so that the additional account magic was >> triggered. But that's likely another story - and it worked perfectly, >> only the messages were a bit confusing. > > Well, it appears you are correct: > http://msdn.microsoft.com/en-us/library/ms724832%28v=VS.85%29.aspx > > Geez, Microsoft sux. > > However, I *wonder* if XP64 is more like NTServer2003, than it is like > XP32. That is, on XP64, does the LocalSystem account in fact HAVE all > the necessary privileges, as it would on XP32 --- or can you only call > LogonUser and friends from a special account on XP64, a restriction > common to NTServer2003 and above? > > Can you *manually* remove the service (cygrunsrv -R tftpd), and then > *manually* re-add the service running under LocalSystem: > > TFTPBOOT=/var/lib/tftpboot > args_value="-L -c -p -u tftpd -U 022 -s ${TFTPBOOT}" > > cygrunsrv -I tftpd -d "CYGWIN tftpd" -p /usr/sbin/tftpd -a "$args_value" > -y tcpip -e CYGWIN="${csih_cygenv}" > > and restart the service. See if it actually runs -- AND, make a large > transfer and use 'ps -eaf' to see if the spawned child tftpd is running > as LocalSystem or the 'tftpd' user.
It seems that XP64 really behaves like NTServer2003 in the sense that LocalSystem cannot change user: I can start the so-created service, but when trying to connect, it fails on fork as expected with "tftpd: PID xxxx: cannot drop privileges: Permission denied." in the Event log. > If it *doesn't* work, then...well, The Right Thing To Do is to fix > is_nt2003 as described above, and then change all the tests for "gee I > need a special privileged user" to > if is_nt2003 || is_xp64 > but that would create a LOT of ripple: every client of csih (cron, exim, > openssh, inetutils, etc etc) is probably already using is_nt2003 for the > same reason and they'd all need to change. So...I think I'd just > declare victory, leave is_nt2003 alone (and wrong), but update the messages. Yes, this seems to be the way to go. Perhaps you could also add some additional comment in front of is_nt2003 explaining the situation? -- Gernot Hillier Siemens AG, CT T DE IT 1, GTF System Architecture & Platforms