Re: [ITP] tftp-hpa 5.0

[Gernot Hillier <gernot dot hillier at siemens dot com>]

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