Has Microsoft lied about the Linux features? - Microsoft Windows

This is a discussion on Has Microsoft lied about the Linux features? - Microsoft Windows ; In news:1064027657@sheol.org, Wayne Throop typed: >>> The claim was it couldn't be done. THe claim is still wrong > >> "ed" >> what was claimed *can't* be done. you can use a work-around to get >> largely the same result, ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 48

Thread: Has Microsoft lied about the Linux features?

  1. Re: Has Microsoft lied about the Linux features?

    In news:1064027657@sheol.org,
    Wayne Throop typed:
    >>> The claim was it couldn't be done. THe claim is still wrong

    >
    >> "ed"
    >> what was claimed *can't* be done. you can use a work-around to get
    >> largely the same result, but it's not the same.

    >
    > The claim was "you can't achieve the result",


    no, the claim was much more specific than that.

    > not that
    > "you can't use ACLs".


    and who claimed that?

    > Nor was "the result" in question one
    > that invoked any of the things ACLs can do that groups can't.
    > You have agreed that one can "get the largely the same result",
    > and since the "largely" includes the functionality of the
    > original claim, that original claim was still wrong.


    dude, you're so out there on this one.

    >> the claim was also regarding what was built-in.

    >
    > Wrong. Here's the quote:
    >
    > "Linux uses clear text for authentication, and does not allow the
    > configurations of individual permissions to the file level.
    > Native support of standard encryption technologies is handled as
    > an add-on."
    >
    > As you can see, the "handled as an add-on" is talking about
    > "support of standard encryption technologies". There is no
    > such clause that applies for per-user permissions.


    the origional quote is from
    http://www.microsoft.com/windows/ser.../compete.mspx; in
    context, it seems obvious to me that they're talking about what's built in.
    but perhaps that's because i'm already familiar w/ the capabilities of both.

    > The closest you can come is to suppose "permissions" encompases those
    > things that ACLs can do that groups can not (ie, differing permission
    > states for the individual, as opposed to "of individuual[s] to the
    > file level". That's an arguable point. The "built-in" isn't.
    >
    > Plus, it's shipped built in in more than one distribution.


    i would argue it's been "pre-added-on" to those distributions. =)

    >> i'm not arguing relative merits- just the claim.

    >
    > Right then. The original claim is still wrong, on two counts.
    >
    > 1. groups can be arranged to match an arbitrary user list
    > to an arbitrary file, and


    which i still think is still a crap argument, because it's a workaround to
    get *group* permissions, not *user* permissions, to do what you want.

    > 2. linux has ACLs


    as an add-on, until 2.5.

    >> as an add-on, until 2.5 becomes the production kernel.

    >
    > Irrelevant, see above. Doubly irrelevant, since it ships
    > built in for more than one distribution.


    arguable. =)

    > Regardless of the claim, I think we agree that
    >
    > 1. ACLs can do things that groups cannot


    yep.

    > 2. linux has ACLs for anybody who wants them
    > and they are enforced by the kernel


    yepl

    > 3. groups can often be (not "always are": just "can *often* be")
    > much easier to adminster than acls (and I've admined both)


    yep.



  2. Re: Has Microsoft lied about the Linux features?

    ed wrote:
    > In news:aAIab.2053$YO5.1494092@news3.news.adelphia.ne t,
    > Lefty typed:
    >> ed wrote:
    >>
    >>> and no, creating groups w/ a single user in them is not a good
    >>> solution.

    >>
    >> because you say so (now)?

    >
    > no, because it's a stupid workaround. there's a reason that there are
    > "users", and "groups". "groups" are, pretty much by definition,
    > meant to contain more than one thing.


    i think that mathmaticians proved long ago that groups can actually contain
    as few as no things and be useful at that.

    if bob is a workgroup of one, then he is. if you and bob are a group of
    two, then you are.

    complaining now that you don't like that solution is weak and petty.




  3. Re: Has Microsoft lied about the Linux features?

    In news:%SZab.2152$YO5.1673328@news3.news.adelphia.ne t,
    Lefty typed:
    > ed wrote:
    >> In news:aAIab.2053$YO5.1494092@news3.news.adelphia.ne t,
    >> Lefty typed:
    >>> ed wrote:
    >>>
    >>>> and no, creating groups w/ a single user in them is not a good
    >>>> solution.
    >>>
    >>> because you say so (now)?

    >>
    >> no, because it's a stupid workaround. there's a reason that there
    >> are "users", and "groups". "groups" are, pretty much by definition,
    >> meant to contain more than one thing.

    >
    > i think that mathmaticians proved long ago that groups can actually
    > contain as few as no things and be useful at that.


    "meant to contain" more than one thing. not "only" contains one thing. not
    "can't" contain more than one thing. not "is not useful" with only one
    thing.

    > if bob is a workgroup of one, then he is. if you and bob are a group
    > of two, then you are.


    gee, really?

    > complaining now that you don't like that solution is weak and petty.


    petty? compared to what- all the other matters of great importance in this
    group? =)



  4. Re: Has Microsoft lied about the Linux features?

    Datagram from Lefty incoming on netlink socket
    <%SZab.2152$YO5.1673328@news3.news.adelphia.net>. Dumping datagram.
    > ed wrote:
    >> In news:aAIab.2053$YO5.1494092@news3.news.adelphia.ne t,
    >> Lefty typed:
    >>> ed wrote:
    >>>
    >>>> and no, creating groups w/ a single user in them is not a good
    >>>> solution.


    Single user groups are very useful, especally as primary group of
    user.

    -Ilari
    --
    I finally installed emacs in UML after getting sick of @!$!%$ vi, and
    I'm fairly impressed by how quick it is. -- Jeff Dike
    Linux LK_Perkele_IV9 2.4.22-rc3 #2 Sun Aug 24 14:36:19 EEST 2003 i686 unknown
    8:02pm up 6 days, 8:01, 12 users, load average: 0.02, 0.08, 0.08

  5. Re: Has Microsoft lied about the Linux features?


    "Ilari Liusvaara" wrote in message
    news:slrnbmp23t.54a.noaddress@LK_Perkele_IV9.local domain...
    > Datagram from Lefty incoming on netlink socket
    > <%SZab.2152$YO5.1673328@news3.news.adelphia.net>. Dumping datagram.
    > > ed wrote:
    > >> In news:aAIab.2053$YO5.1494092@news3.news.adelphia.ne t,
    > >> Lefty typed:
    > >>> ed wrote:
    > >>>
    > >>>> and no, creating groups w/ a single user in them is not a good
    > >>>> solution.

    >
    > Single user groups are very useful, especally as primary group of
    > user.


    But how could a group of one be better than per user ACLs?



  6. Re: Has Microsoft lied about the Linux features?

    begin In <1445a2d7.0309181035.2f1e6719@posting.google.com>, on
    09/18/2003
    at 11:35 AM, totojepast@atlas.cz (totojepast) said:

    >Subject: Has Microsoft lied about the Linux features?


    Is the Pope Catholic? Lying is one of his job functions; why does it
    surprise you?

    --
    Shmuel (Seymour J.) Metz, SysProg and JOAT

    Unsolicited bulk E-mail will be subject to legal action. I reserve
    the right to publicly post or ridicule any abusive E-mail.

    Reply to domain Patriot dot net user shmuel+news to contact me. Do
    not reply to spamtrap@library.lspace.org


  7. Re: Has Microsoft lied about the Linux features?

    Shmuel (Seymour J.) Metz writes:

    > Is the Pope Catholic? Lying is one of his job functions; why does it
    > surprise you?


    On what basis do you claim that lying is one of the Pope's job
    functions, Metz?


  8. Re: Has Microsoft lied about the Linux features?

    Hello World,

    >>I guess no one at MS ever did an "ls -l" to see what permissions were
    >>set to at the file level (and directory level).


    ed wrote:
    > they're probably talking about setting permissions at the file level for
    > individuals- there's only world, group, and owner permissions. if i wanted
    > to give "bob" permission to my file, but nobody else in bob's groups,
    > there's no easy way to do this.


    Well, IBM's AIX does allow you to set Access Control Lists. (And so, by
    the way, does Warp Server). It is probably the least used feature, maybe
    after file systems quotas. I don't know if Linux has this in the works,
    but demand doesn't seem to be soaring.

    Typical. Blow up the non-essentials and let the users find out about the
    crap after they've bought.

    Cheers/2,
    Menno


  9. Re: Has Microsoft lied about the Linux features?

    On Wed, 01 Oct 2003 21:05:54 +0200, Menno Willemse
    wrote:

    >Hello World,
    >
    >>>I guess no one at MS ever did an "ls -l" to see what permissions were
    >>>set to at the file level (and directory level).

    >
    >ed wrote:
    >> they're probably talking about setting permissions at the file level for
    >> individuals- there's only world, group, and owner permissions. if i wanted
    >> to give "bob" permission to my file, but nobody else in bob's groups,
    >> there's no easy way to do this.

    >
    >Well, IBM's AIX does allow you to set Access Control Lists. (And so, by
    >the way, does Warp Server). It is probably the least used feature, maybe
    >after file systems quotas. I don't know if Linux has this in the works,
    >but demand doesn't seem to be soaring.
    >
    >Typical. Blow up the non-essentials and let the users find out about the
    >crap after they've bought.


    I hope you're kidding about the above. The scenario described there
    is commonplace in today's working world.

  10. Re: Has Microsoft lied about the Linux features?

    Hello World,

    foo@bar.com wrote:
    >>ed wrote:
    >>
    >>>they're probably talking about setting permissions at the file level for
    >>>individuals- there's only world, group, and owner permissions. if i wanted
    >>>to give "bob" permission to my file, but nobody else in bob's groups,
    >>>there's no easy way to do this.

    >>
    >>Well, IBM's AIX does allow you to set Access Control Lists. (And so, by
    >>the way, does Warp Server). It is probably the least used feature, maybe
    >>after file systems quotas. I don't know if Linux has this in the works,
    >>but demand doesn't seem to be soaring.

    >
    > I hope you're kidding about the above. The scenario described there
    > is commonplace in today's working world.


    No I'm not. Hardly anybody uses file-level security under Windows or
    Unix. The usual way people do it is to create a shared directory where
    you put stuff that you want your colleagues to look at. The most common
    method I've seen for file sharing among Windows users is to email them a
    copy. Now inside databases is another story...

    Cheers/2,
    Menno


  11. Re: Has Microsoft lied about the Linux features?

    On Thu, 2 Oct 2003 11:06:53 UTC, Menno Willemse wrote:

    >Hello World,
    >
    >foo@bar.com wrote:
    >>>ed wrote:
    >>>
    >>>>they're probably talking about setting permissions at the file level for
    >>>>individuals- there's only world, group, and owner permissions. if i wanted
    >>>>to give "bob" permission to my file, but nobody else in bob's groups,
    >>>>there's no easy way to do this.
    >>>
    >>>Well, IBM's AIX does allow you to set Access Control Lists. (And so, by
    >>>the way, does Warp Server). It is probably the least used feature, maybe
    >>>after file systems quotas. I don't know if Linux has this in the works,
    >>>but demand doesn't seem to be soaring.

    >>
    >> I hope you're kidding about the above. The scenario described there
    >> is commonplace in today's working world.

    >
    >No I'm not. Hardly anybody uses file-level security under Windows or
    >Unix. The usual way people do it is to create a shared directory where
    >you put stuff that you want your colleagues to look at. The most common
    >method I've seen for file sharing among Windows users is to email them a
    >copy. Now inside databases is another story...


    If you have a shared directory in Unix, and you copy a file into it
    that doesn't have either global or group read bit set, the fact that
    it's in a shared directory on the system won't permit other people
    to read it.

    This means that you can put a file out in public and by setting the
    right bits keep it to yourself. There are times when this is useful.

    Regards,

    Jack

    --
    -------------------------------------------------------------------
    * Jack Troughton jake at consultron.ca *
    * http://consultron.ca irc.ecomstation.ca *
    * Kingston Ontario Canada news://news.consultron.ca *
    -------------------------------------------------------------------


  12. Re: Has Microsoft lied about the Linux features?

    On Thu, 02 Oct 2003 13:06:53 +0200, Menno Willemse
    wrote:

    >Hello World,
    >
    >foo@bar.com wrote:
    >>>ed wrote:
    >>>
    >>>>they're probably talking about setting permissions at the file level for
    >>>>individuals- there's only world, group, and owner permissions. if i wanted
    >>>>to give "bob" permission to my file, but nobody else in bob's groups,
    >>>>there's no easy way to do this.
    >>>
    >>>Well, IBM's AIX does allow you to set Access Control Lists. (And so, by
    >>>the way, does Warp Server). It is probably the least used feature, maybe
    >>>after file systems quotas. I don't know if Linux has this in the works,
    >>>but demand doesn't seem to be soaring.

    >>
    >> I hope you're kidding about the above. The scenario described there
    >> is commonplace in today's working world.

    >
    >No I'm not. Hardly anybody uses file-level security under Windows or
    >Unix. The usual way people do it is to create a shared directory where
    >you put stuff that you want your colleagues to look at. The most common
    >method I've seen for file sharing among Windows users is to email them a
    >copy. Now inside databases is another story...
    >


    Menno, do you work for a large company? It sure doesn't sound like
    it.

    My company has around 70,000 employees and we use file permissions
    *everywhere*. If you are not then I can only assume that you have no
    need for any kind of security, and that there is no concept of
    confidential data in your workplace - in which case you are probably
    breaking a number of privacy laws.

    >Cheers/2,
    >Menno


    Regards,
    David Sutherland
    (note **ANTI-SPAM** in reply field)

  13. Re: Has Microsoft lied about the Linux features?

    David Sutherland writes:

    > My company has around 70,000 employees and we use file permissions
    > *everywhere*. If you are not then I can only assume that you have no
    > need for any kind of security, and that there is no concept of
    > confidential data in your workplace - in which case you are probably
    > breaking a number of privacy laws.


    Gad, how uninformed can a person be? I have no need for file
    permissions on my PC, Sutherland, yet the data are quite confidential,
    despite the fact that my "company" has thousands of employees. If
    you can't figure out why, that's your problem, Sutherland.


  14. Re: Has Microsoft lied about the Linux features?

    Hello World,

    >>No I'm not. Hardly anybody uses file-level security under Windows or
    >>Unix. The usual way people do it is to create a shared directory where
    >>you put stuff that you want your colleagues to look at. The most common
    >>method I've seen for file sharing among Windows users is to email them a
    >>copy. Now inside databases is another story...


    Jack Troughton wrote:
    >
    > If you have a shared directory in Unix, and you copy a file into it
    > that doesn't have either global or group read bit set, the fact that
    > it's in a shared directory on the system won't permit other people
    > to read it.
    >
    > This means that you can put a file out in public and by setting the
    > right bits keep it to yourself. There are times when this is useful.


    Okay... Let's have the whole story out, then. Under Unix (for all values
    of "Unix"), any file and any directory has some bits that determine who
    can do what to the file. I'll concentrate first on the most obvious ones.

    When you do a "ls -l" in a directory, you might see something like this:

    total 1
    drwxr-x--- 2 mrw flexor 512 Oct 06 22:40 dir
    -rw-r----- 1 mrw usr 0 Oct 06 22:40 fil
    -rwxr-xr-x 1 mrw usr 0 Oct 06 22:40 program

    The first letter can be (among others) a dash for a normal file and a
    "d" for a directory. (Yes, there's also links, special devices and
    sockets, but let's keep this simple for now). The next nine spaces are
    either dashes or the letters "r", "w" or "x". R is for Read, W is for
    Write and X is for eXecute. There are three groups of these.

    The first three letters affect the owner of the file or directory. In
    this case "mrw" - Me. You can see I have read and write rights on the
    "fil" file, but not execute. (No point as it's not a program).

    The second group of rwx applies to the group. For instance: the
    directory "dir" belongs to the group "flexor". So everyone in group
    "flexor" has read and execute rights on the directory. (I'll explain
    what that means in a bit).

    The third group is for "Everybody else". Which in some cases means
    "anyone with an account on this machine", or when you NFS-export the
    directory, "anyone with an NFS-capable computer on the network".

    Now what do these letters mean? Okay... normal files first. Read and
    write are obvious. Execute means that if the file is a program, you can
    run it. When the file is a binary executable, you only need the x bit to
    run the program, but if the file is a shell script (bourne, korn,
    cshell, perl script or basically any program that can read instructions
    from a file) you need read rights as well.

    For directories, read rights mean you can list the directory, basically.
    A Unix directory can be opened and read just like a normal file but not
    written to (which is good as you can only bugger it up). If you have
    write permission on a directory, you can put files in it or remove the
    files. You can even remove files that don't belong to you because a file
    removal is a modification to the directory, not the file. The rm command
    will warn you before doing it, though. Execute permission on a directoey
    means that you are able to access files in it or cd to it. You don't
    need read permission on a directory to access a file in it. If you know
    the name of the file, you can open it. What you can do with it depends
    on that file's permissions.

    You can specify permission bits in a symbolic form (ug+rx means Add Read
    and Execute for User and Group) or in its numerical form, which requires
    some binary arithmetic. R has the value 4, W has the value 2 and X has
    the value 1. So if you want to set the permissions to everything for
    yourself, read and write for the group members and execute-only for the
    rest, the resulting permission bits are 761. The standard
    look-but-don't-touch permission is 644, 755 for directories.

    Now there are some more nice bits to play with: namely the set-user-id
    bit and the set-group-id bit. For a program, this does what it looks
    like: when you execute the program, you switch temporarily to that user.
    The program can then do whatever that user could do. (Debug setuid
    programs with a big dose of paranoia!) The same goes for the setgid bit:
    When you execute a setgid program, you can access files if the group has
    the appropriate permissions.

    For a directory, the setuid bit does nothing useful, but the setgid
    does: Whenever someone places a file in the given directory, that file
    will be placed under the group ownership of that directory.

    And that's the feature most commonly used to shatre files among bigger
    or smaller groups of people. You create a group of select individuals,
    then you create a setgid directory where you place the files that you
    are working on together. If you set your umask right, you will be able
    to read and write each other's files.

    What's a umask? Well... it's a number inside your Unix environment that
    determines the permissions you set on files and directories. Those
    perverts who designed Unix decided to use the *reverse image* of the
    permissions for the umask. So a umask of 027 will set your new files to
    750 or rwxr-x---. Only on files, the x bits don't get set even if you DO
    specify it in your umask. So a umask of 022 (which is pretty common)
    will have you create directories with 755 permissions and files with 644
    permissions.

    And that, basically, is the story of the Unix Permission Bits.


    Cheers/2,
    Menno


  15. Re: Has Microsoft lied about the Linux features?

    On Tue, 07 Oct 2003 00:01:00 +0200, Menno Willemse wrote:

    [lots of stuff snipped]

    You forgot to mention the "sticky bit"... which is quite handy... you can
    set it on the directory and users in the group can read files that have
    group permissions set BUT not overwrite, delete, or move files that they
    don't own and have permissions to write to. It basically allows one to
    share files but makes it impossible for someone else in the group to
    inadvertently (or otherwise) to delete or alter the shared file.
    If you are not sure what the sticky bit is... look it up.

    -DU-...etc...

  16. Re: Has Microsoft lied about the Linux features?

    David Utidjian wrote:
    > On Tue, 07 Oct 2003 00:01:00 +0200, Menno Willemse wrote:
    >
    > [lots of stuff snipped]
    >
    > You forgot to mention the "sticky bit"... which is quite handy... you can
    > set it on the directory and users in the group can read files that have
    > group permissions set BUT not overwrite, delete, or move files that they
    > don't own and have permissions to write to.


    Ah, yes. The /tmp directory has it by default, for one.

    Cheers/2,
    Menno


  17. Re: Has Microsoft lied about the Linux features?

    David Sutherland wrote:
    >
    > Menno, do you work for a large company? It sure doesn't sound like
    > it.


    I do fee services for banks and insurance companies. Though I must admit
    that the machines I work with are Unix database servers and application
    servers. Users don't generally access these machines directly. They use
    some sort of application client on their PCs (like SAP for instance).
    The application decides whether or not you are allowed to do a certain
    action. This does not require the use of individual rights on files.

    What you do on a server is create a special application administrator
    and put all the files and the processes that access them under the user
    ID of that application user. "Bob" isn't even allowed to look at the
    files, let alone touch them.

    > My company has around 70,000 employees and we use file permissions
    > *everywhere*. If you are not then I can only assume that you have no
    > need for any kind of security, and that there is no concept of
    > confidential data in your workplace - in which case you are probably
    > breaking a number of privacy laws.


    On noooo! I may be breaking a number of privacy laws! A deeply worried
    look passes over my face.

    I think my company is actually in the same size category worldwide and
    trust me, we have our files locked up tight. Still, the original point
    was that you couldn't easily hand out permissions to Bob. What you do
    under Unix is create a shared directory, put it under group ownership of
    an appropriate group and add everybody to the group that you need to
    access the file (from zero to infinite). Neat and tidy. No need to
    resort to access control lists.

    People find it easier to relate the relative security of a file to the
    place where they put it. Put the file on the shared drive and others can
    read it. Put it on your own drive and only you can touch it.

    There is another security issue with this: Most programs under Windows
    make backups of an old file by renaming it to .BAK or some such and
    writing a new copy of the file. That clears up any security parameters
    you may have set on your file as they are now on the backup copy. Just
    try explaining that to your average secretary or lawyer.

    Just because you don't use ACLs doesn't mean your files are insecure.
    Unix already had a concept of file and directory level security back
    when Windows was still a DOS extender. If having ACLs would have been
    helpful, the folks would have implemented them.

    Cheers/2,
    Menno


  18. Re: Has Microsoft lied about the Linux features?

    On Tue, 07 Oct 2003 09:45:10 +0200, Menno Willemse
    wrote:

    >David Sutherland wrote:
    >>
    >> Menno, do you work for a large company? It sure doesn't sound like
    >> it.

    >
    >I do fee services for banks and insurance companies. Though I must admit
    >that the machines I work with are Unix database servers and application
    >servers. Users don't generally access these machines directly. They use
    >some sort of application client on their PCs (like SAP for instance).
    >The application decides whether or not you are allowed to do a certain
    >action. This does not require the use of individual rights on files.
    >


    So you don't work in an area where file security is deployed. That's
    fine, but don't take that to mean that it isn't used elsewhere.

    One simple example: At my firm all users desktops are locked down,
    and their personal documents folders are network mounted. In
    addition to their personal files their are many terrabytes of shared
    folders which use ACL's to ensure user and group access privileges.

    Financial houses *must* by law take all due diligence to prevent
    unauthorised access to private data. The fines for failing to do so
    are prohibitive.

    >What you do on a server is create a special application administrator
    >and put all the files and the processes that access them under the user
    >ID of that application user. "Bob" isn't even allowed to look at the
    >files, let alone touch them.
    >


    Auditing? How do you know who last made a change?

    >> My company has around 70,000 employees and we use file permissions
    >> *everywhere*. If you are not then I can only assume that you have no
    >> need for any kind of security, and that there is no concept of
    >> confidential data in your workplace - in which case you are probably
    >> breaking a number of privacy laws.

    >
    >On noooo! I may be breaking a number of privacy laws! A deeply worried
    >look passes over my face.
    >


    That you have said you do work for banks *and* don't care about
    privacy laws suggests that you have no business working for those
    clients. The Legal and Compliance people would not let you set foot
    in the door if they knew that this is your attitude to client
    confidentiality. You may work in the industry, but you just lost any
    claim to being a *professional* in it.

    >I think my company is actually in the same size category worldwide and
    >trust me, we have our files locked up tight.


    Except where you don't care about privacy laws and confidentiality!

    How do you deal with shared folders?

    >Still, the original point
    >was that you couldn't easily hand out permissions to Bob.


    No - you'r original point was that "hardly anybody uses file-level
    security under Windows or Unix. "

    This is nonsense - every single organisation I have worked for has
    employed file permissions for both Unix and Windows. Every single
    one.

    >What you do
    >under Unix is create a shared directory, put it under group ownership of
    >an appropriate group and add everybody to the group that you need to
    >access the file (from zero to infinite). Neat and tidy. No need to
    >resort to access control lists.
    >


    This is in direct contradiction with your previous claim that "hardly
    anybody uses file-level security under Windows or Unix."

    Make up your mind! Are they using it or aren't they?

    >People find it easier to relate the relative security of a file to the
    >place where they put it. Put the file on the shared drive and others can
    >read it. Put it on your own drive and only you can touch it.
    >


    And if the desktop doesn't permit local storage other than temporary
    files?

    >There is another security issue with this: Most programs under Windows
    >make backups of an old file by renaming it to .BAK or some such and
    >writing a new copy of the file. That clears up any security parameters
    >you may have set on your file as they are now on the backup copy. Just
    >try explaining that to your average secretary or lawyer.
    >


    Try explaining it to me instead. What programs do you have in mind
    that are creating all these ".bak" files?

    >Just because you don't use ACLs doesn't mean your files are insecure.


    If you don't use file/directory permissions on shared drives then your
    files are most certainly insecure.

    >Unix already had a concept of file and directory level security back
    >when Windows was still a DOS extender. If having ACLs would have been
    >helpful, the folks would have implemented them.
    >


    Sorry - what's your point with this?

    You claimed that "hardly anybody uses file-level security under
    Windows or Unix" and now you are claiming that Unix files security has
    been in pervasive use for years. You are contradicting yourself!

    >Cheers/2,
    >Menno


    Regards,
    David Sutherland
    (note **ANTI-SPAM** in reply field)

  19. Re: Has Microsoft lied about the Linux features?

    Hello World,

    David Sutherland wrote:
    > On Tue, 07 Oct 2003 09:45:10 +0200, Menno Willemse
    > wrote:
    >
    > One simple example: At my firm all users desktops are locked down,
    > and their personal documents folders are network mounted. In
    > addition to their personal files their are many terrabytes of shared
    > folders which use ACL's to ensure user and group access privileges.


    Are there actually ACLs on those files that say "jane and bob can use
    this file"? Or are they in a directory where the workgroup in question
    has access?

    >>On noooo! I may be breaking a number of privacy laws! A deeply worried
    >>look passes over my face.

    >
    > That you have said you do work for banks *and* don't care about
    > privacy laws suggests that you have no business working for those
    > clients.


    Pardon me for using sarcasm on those ill-equipped to deal with it.

    > How do you deal with shared folders?


    mkgroup happyfew # The folks who want to share files
    mkdir /data/happyfew # Their place for doing so
    chgrp happyfew /data/happyfew # Put the place under the group's ownership
    chmod 770 /data/happyfew # Give only the owner and group all rights, none
    chmod g+s /data/happyfew # Inherit group from directory
    chgrp "users=bob,jane,henry" happyfew # Let in the users.

    Then, Bob, Jane and Henry put their files in /data/happyfew and nobody
    except them can access 'em. You can pull more fancy stuff and create
    subdirectories where only the owner and their managers have rights. This
    is directory-level/group-level security, which *is* in common use.

    > No - you'r original point was that "hardly anybody uses file-level
    > security under Windows or Unix. "


    Hope the above clarifies what I meant.

    > This is nonsense - every single organisation I have worked for has
    > employed file permissions for both Unix and Windows. Every single
    > one.


    Well pardon my loose wording then. What I meant to say is that people
    generally don't fiddle with ACLs on individual files as it's basically
    too much trouble to take.

    > This is in direct contradiction with your previous claim that "hardly
    > anybody uses file-level security under Windows or Unix."
    >
    > Make up your mind! Are they using it or aren't they?


    You know, you *could* have asked what I meant. You *could* have read the
    post that sparked off this whole tirade and found out what I was talking
    about. Instead, you choose to come out at me, fangs bare and slavering,
    claiming that I'm unfit for my job. Someone with your obvious lack of
    communicative abilities should not be allowed in any customer-facing
    job. Hope they keep you in a nice air-conditioned computer room and
    leave the talking to others.

    Cheers/2,
    Menno


  20. Re: Has Microsoft lied about the Linux features?

    On Tue, 7 Oct 2003 20:58:50 UTC, Menno Willemse wrote:

    > Hello World,
    >
    > David Sutherland wrote:
    > > On Tue, 07 Oct 2003 09:45:10 +0200, Menno Willemse
    > > wrote:




    > Someone with your obvious lack of
    > communicative abilities should not be allowed in any customer-facing
    > job. Hope they keep you in a nice air-conditioned computer room and
    > leave the talking to others.


    Hehe. Guess they forgot to restrict his Internet access.

    --
    Best regards
    Sten Solberg

    .... Also sprach Zarathustra: "Have a Good Day!"


+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast