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.

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? =)

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

"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?

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

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?

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

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.

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

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 *
-------------------------------------------------------------------

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)

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.

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

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...

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

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

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)

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

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!"