 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson <nos### [at] nospam com> wrote:
> On Mon, 12 Sep 2011 21:17:02 +0100, Orchid XP v8 wrote:
> > I'm not aware of any Unix system which *defaults* to letting remote
> > users access the entire filesystem if they know the root password.
> > Probably because it's a stunningly bad idea, unless the local network is
> > trusted. But anyway...
> Every unix system can do this with something like sshfs installed - on
> the client side only - and sshd running on the server.
Anyways, sharing an entire file system is often overkill, if your goal
is to simply transfer one file to another person.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> > Of course this requires for one of the computers to act as a server.
> > This is made difficult in Windows. (Yes, I know it's not impossible.
> > I didn't say that.)
> Transferring files in Windows is trivial. You RDP into the other machine,
> and use copy/paste just like in the file manager. Or you mount the share off
> the other machine. Or let RDP mount the share for you.
I like how to you everything in Windows is "trivial". Like using soft or
hard links (which, btw, I have still no idea how to do, regardless of your
assurances that it's very easy).
(If this so "trivial", why haven't I ever heard of this "RDP"? Yes, this
is the first time in my life I hear of it. And it's not like I haven't been
using Windows pretty regularly for the past 15 years or so. Contrast me
knowing about tools like rsync, rcp, scp and wget, which arguably are not
the most obvious things in unix either. What is the difference?)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/09/2011 11:58 PM, Darren New wrote:
> On 9/12/2011 14:39, Orchid XP v8 wrote:
>> I've never used Skype. But I've used various IM clients. And my point is,
>> they all tend to be inexplicably slow to transfer files.
>
> They're generally not transferring directly between machines, since your
> machine is normally behind a NAT. There's a server with a public IP
> address in between.
Quite. And that presumably is where the transfer is getting throttled.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 13/09/2011 08:22 AM, Warp wrote:
> Orchid XP v8<voi### [at] devnull> wrote:
>> While we're on the subject, by default you can log in to any remote
>> Windows PC that you happen to know the administrator password to. No
>> special software required. Again, try getting X11 to let you do that.
>> Good luck.
>
> Did you know that the X windowing system was actually designed from the
> very beginning to run remotely? Running it locally was just a "free" feature
> on top of that.
Yes indeedy. (I also know that they got the usual meanings of "server"
and "client" backwards too.)
Now I haven't tried it, but I'm told is approximately /impossible/ to
actually configure X so that you can access it remotely. Even though
that's its entire design goal.
> It's Windows that was designed to be a purely local system, and to which
> remote running was patched in later.
And yet, Windows is the one where I run a command, type in the name of
any networked PC, and I have remote access. By default. No special
configuration required.
(OTOH, doesn't X allow more than one user to log in at once? With
Windows, that's a special extra feature that costs $$$.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/09/2011 10:20 PM, Jim Henderson wrote:
> On Mon, 12 Sep 2011 21:17:02 +0100, Orchid XP v8 wrote:
>
>> I'm not aware of any Unix system which *defaults* to letting remote
>> users access the entire filesystem if they know the root password.
>> Probably because it's a stunningly bad idea, unless the local network is
>> trusted. But anyway...
>
> Every unix system can do this with something like sshfs installed - on
> the client side only - and sshd running on the server.
Yes, if you /install stuff/ you can do it.
My point is that Windows lets you do this by default. Nothing to
install, nothing to configure. It's the *default* configuration state,
unless you purposely changed it.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 13/09/2011 08:16 AM, Warp wrote:
> clipka<ano### [at] anonymousorg> wrote:
>> Am 12.09.2011 22:17, schrieb Orchid XP v8:
>
>>> I'm not aware of any Unix system which *defaults* to letting remote
>>> users access the entire filesystem if they know the root password.
>>> Probably because it's a stunningly bad idea, unless the local network is
>>> trusted. But anyway...
>
>> To the contrary: Unix doesn't only let users who know the root password
>> access the /filesystem/, but do /anything/ they like on the machine.
>
> Except that most unix systems have been configured so that you *can't*
> log in as root remotely. The system simply refuses to accept the login.
>
> Anyways, that's besides the point of transferring files. Being able to
> log in as root (remotely or not) has nothing to do with the ability to
> transfer files from one computer to another.
Sure. My point was, if you do a default install of Windows, you /can/
get and put files to it remotely. Under Unix, you'd have to install some
stuff and configure it before that would work. (Argue amongst yourselves
which one is better...)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 09/13/2011 04:16 AM, Warp wrote:
> clipka<ano### [at] anonymousorg> wrote:
>> Am 12.09.2011 22:17, schrieb Orchid XP v8:
>
>>> I'm not aware of any Unix system which *defaults* to letting remote
>>> users access the entire filesystem if they know the root password.
>>> Probably because it's a stunningly bad idea, unless the local network is
>>> trusted. But anyway...
>
>> To the contrary: Unix doesn't only let users who know the root password
>> access the /filesystem/, but do /anything/ they like on the machine.
>
> Except that most unix systems have been configured so that you *can't*
> log in as root remotely. The system simply refuses to accept the login.
generally true enough, but there's always exceptions, any system(s)
expected to be able to pass a security audit wouldn't allow this,
because YES it's generally considered bad practice, however there were
occasions that grabbing the system console remote was/is necessary ...
ie: problem with root filesystem (need for fsck before the filesystem is
mounted), but the audit trail required an incident report to explain why
the access occurred ... most if not all sys admin tasks /should/ be done
via sudo/su2 so as to NOT break the audit trail. Our security expert was
a fanatic about this ... he even came up with a "bone-head" trophy that
you were expected to display prominently, so other members of the admin
team could publicly ridicule you for using "root" without a good reason
... mandate from above was that protecting R&D systems and data was
SERIOUS business.
>
> Anyways, that's besides the point of transferring files. Being able to
> log in as root (remotely or not) has nothing to do with the ability to
> transfer files from one computer to another.
yep ... general access was setup so that a user either through uid/gid
affiliation gets effectively painted into a corner
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 09/13/2011 05:06 AM, Invisible wrote:
> On 13/09/2011 08:22 AM, Warp wrote:
>> Orchid XP v8<voi### [at] devnull> wrote:
>>> While we're on the subject, by default you can log in to any remote
>>> Windows PC that you happen to know the administrator password to. No
>>> special software required. Again, try getting X11 to let you do that.
>>> Good luck.
>>
>> Did you know that the X windowing system was actually designed from the
>> very beginning to run remotely? Running it locally was just a "free"
>> feature
>> on top of that.
>
> Yes indeedy. (I also know that they got the usual meanings of "server"
> and "client" backwards too.)
>
> Now I haven't tried it, but I'm told is approximately /impossible/ to
> actually configure X so that you can access it remotely. Even though
> that's its entire design goal.
easy on "nix" systems ... through a socket!
>
>> It's Windows that was designed to be a purely local system, and to which
>> remote running was patched in later.
>
> And yet, Windows is the one where I run a command, type in the name of
> any networked PC, and I have remote access. By default. No special
> configuration required.
>
> (OTOH, doesn't X allow more than one user to log in at once? With
> Windows, that's a special extra feature that costs $$$.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 13/09/2011 08:30 AM, Warp wrote:
> I like how to you everything in Windows is "trivial". Like using soft or
> hard links (which, btw, I have still no idea how to do, regardless of your
> assurances that it's very easy).
End users aren't supposed to use this technology. It's used "under the
hood" by various Windows features. Remember, the desktop Windows OS is
designed to be operated by morons.
(For example, most of our salesman have a Windows laptop. And trust me,
they are idiots of the highest calibre.)
> If this so "trivial", why haven't I ever heard of this "RDP"?
Because Microsoft refers to it by half a dozen different names.
Terminal Services.
Remote Desktop.
Remote Assistance.
RDP stands for Remote Desktop Protocol, and is the actual wire protocol
underlying all of the above /product features/.
Terminal Services is where you have an expensive server-class version of
Windows, you install all your complicated applications on that, and then
end users use their Windows-based desktop PC to log into the server and
run the applications on that. In other words, each desktop PC becomes
essentially a dumb terminal for connecting to the server where the
applications actually run.
Remote Desktop is where you log in to a remote desktop system in the
same way you'd log in to it remotely. Except... it's remote. To anybody
looking at the desktop locally, it just looks like the system is locked.
Because it's a /desktop/ system, only one user can be logged in to it at
once, remotely or locally.
Remote Assistance is where a computer wizard logs in to your PC
remotely, but you still have control and you can see what they're doing.
And there's a system for sending "help requests" or sending "help
offers". And so forth.
I'm not 100% sure, but I think Windows Live Meeting might be using this
as well. (It lets several people text or voice chat in realtime, and
allows a "presenter" to share either a live video feed, or a live image
of their desktop.)
What all these systems have in common is that one computer is displaying
the video output of another. Like a remote X session. Except that it
also connects the sound card, network drives, printers [but that never
****ing works properly], clipboard, and probably a few other things as well.
This is literally how when I have a day off work, I can sit at my home
PC and reboot servers, install software updates, and all kinds of other
stuff, from my house. (Obviously, there's a VPN involved as well.
Otherwise all this traffic would be unencrypted...)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> You can thank Windows for this.
>
> Nah. You can thank NAT for this.
I think it's more the general problem of Internet security. If you
expose a service to the Internet, random people will try to hack it.
Security is a Hard Problem.
> Note how all of those require a running server on a public IP address.
Well, yes. To perform a data transfer, you need a way to contact the
other end.
I'm told there's a system called UPnP or something which is supposed to
allow you to automatically bypass NAT. I have no idea whether this
actually works. (It's the first time I've ever heard of it...) If it
does work, NAT should be a non-issue.
>> Of course this requires for one of the computers to act as a server.
>> This is made difficult in Windows. (Yes, I know it's not impossible.
>> I didn't say that.)
>
> Transferring files in Windows is trivial. You RDP into the other
> machine, and use copy/paste just like in the file manager. Or you mount
> the share off the other machine. Or let RDP mount the share for you.
It's news to me that you can transfer files with RDP. Indeed, that's one
of the frustrating things about it; it let's you control the remote
machine, but not get data to it or from it.
>> If you are regularly transferring files to someone, just make him install
>> skype.
>
> Or any IM client, really.
Pretty much, yeah...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
