 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 13/09/2011 08:16 AM, Warp wrote:
> clipka<ano### [at] anonymous org> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> Under Unix, you'd have to install some
> stuff and configure it before that would work. (Argue amongst yourselves
> which one is better...)
I really can't understand where you are getting this from. Not from what
I said, at least. I said that transferring files has been one of the core
features of unix from the very beginning. You make it sound like I had said
the exact opposite: That you need to do a lot of work to achieve that.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 13/09/2011 11:12 AM, Warp wrote:
> Invisible<voi### [at] devnull> wrote:
>> Under Unix, you'd have to install some
>> stuff and configure it before that would work. (Argue amongst yourselves
>> which one is better...)
>
> I really can't understand where you are getting this from. Not from what
> I said, at least. I said that transferring files has been one of the core
> features of unix from the very beginning. You make it sound like I had said
> the exact opposite: That you need to do a lot of work to achieve that.
You said that it's always been easy to transfer files with Unix, and
that Windows makes it far too difficult.
I said that Windows allows it *by default*, whereas under Unix you'd
have to set up and configure a bunch of stuff first.
So, by my reckoning, transferring files is *easier* with Windows, not
harder.
Now, if you want to talk about *security*, that's an entire other topic
of course...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> 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.
I don't know what you mean.
For the sake of it, I just now tried to do a "ssh -X" to a friend's computer
(who is also running linux) and ran xclock. It opened nicely on my screen,
even though the program itself is running on my friend's computer (which is
physically located something like 200 km from here).
(For some reason xclock is the de-facto "standard" X program to test
running X apps remotely. Probably because it's very light and ubiquitous
in all X installations.)
Yes, you have to specify a special parameter to ssh in order to enable
X forwarding, but that's for safety reasons rather than anything else.
> > 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.
What kind of configuration did I do to be able to log in into my friend's
computer and run an app remotely? Or to transfer files for that matter (which
was the original point)?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> 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.
I don't think Windows uses soft links itself either. Soft links are
supported by NTFS, but I don't think Windows itself uses them for anything.
(After all, Windows has to be able to work if installed on a FAT32 partition
too.) Same's probably true for hard links.
(And no, "shortcuts" are not soft links. They are a completely different
thing.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 13/09/2011 11:28 AM, Warp wrote:
> Invisible<voi### [at] devnull> wrote:
>> 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.
>
> I don't think Windows uses soft links itself either. Soft links are
> supported by NTFS, but I don't think Windows itself uses them for anything.
> (After all, Windows has to be able to work if installed on a FAT32 partition
> too.) Same's probably true for hard links.
I'm fairly sure System Restore uses hardlinks. (Not that you can tell by
looking at it.) At least, it does on NTFS. On FAT, it presumably makes
copies of the files. Then again, there's all sorts of features that
don't work on FAT and only work on NTFS. (For example, I believe
"offline folders" only works for NTFS.)
> (And no, "shortcuts" are not soft links. They are a completely different
> thing.)
No, they aren't. They are special files that are interpreted by Windows
Explorer. The hold no special significance for any other programs.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
