ownership/permissions question

[crankypuss]

There is a directory that I want to be read/write for me, read/only for
group, and inaccessible for others.

I tried setting it up as "D -G- rwx r-x ---" with owner=1000 and
group=1003. That worked fine with one exception. Anything that I
copied to or saved to the directory turned out to be "F --- rw- rw- r--".

So I went back to owner=1000 group=1000 and "D -G- rwx rwx r--" which
seems to be working better except that now "world" has read access, when
I really just want group=1003 to have read access.

At least it prevents my effectively giving r/w access to group=1003 when
I'm working stupid (ie, sleep-deprived, my usual state).

So... someone (unruh?) said there was a way to make directory
permissions fully hierarchical. I'm wondering if there's a trick I
haven't tried, or if, although directory permissions can be made fully
hierarchical the files within them are subject to access by those who
know/guess their filespec.

For a directory you want to be r/w for yourself, r/o to group, and
inaccessible to others, what's the correct way to set it up?

[Aragorn]

On Tuesday 02 April 2013 22:51, crankypuss conveyed the following to
alt.os.linux...

$ chmod 2750 $DIRECTORY

... will result in the permissions you want, with the SGID bit set.
This will cause everything which is newly added to the directory to have
the same GID as the directory itself. For stuff that's already in the
directory, you will have to issue a...

$ chgrp -R $GROUP $DIRECTORY

... or alternatively...

$ chown -R ${USER}:${GROUP} $DIRECTORY

You also might want to look into setting a umask in your ~/.bashrc and -
if it exists - your ~/.xinitrc for setting default permissions on any
newly created files. Don't do this via /etc/bashrc, because the root
user should have a 022 umask.

--
= Aragorn =
GNU/Linux user #223157 - http://www.linuxcounter.net

[Lew Pitcher]

On Tuesday 02 April 2013 16:51, in alt.os.linux, crank...@nomail.invalid
wrote:

> There is a directory that I want to be read/write for me, read/only for
> group, and inaccessible for others.

1) chown the directory so that you are the user owner, and the appropriate
group is the group owner
2) chmod the directory to 640, so that user gets read and write access, the
group gets read access, and all others gets no access

Note: you /might/ consider permit "execute" access on the directory for
user, and possibly for group, as without it, you cant chdir into the
directory. This would mean permissions of 740 or 750, depending.

> I tried setting it up as "D -G- rwx r-x ---"

Huh? I'm not familiar with this notation. My /guess/ is that
- the "D" stands for directory,
- the "-G-" stands for "SetGID permission",
- the "rwx" stands for "User read, write, & execute permissions",
- the "r-x" stands for "group read and execute permissions", and
- the "---" stands for "other, no permissions".

It would have been clearer if you just expressed the permissions as their
octal number.

So, you selected BSD semantics for the directory, so that
- files created in the directory are assigned to the directory group owner
- directories created in the directory will inherit the SetGID bit

> with owner=1000 and
> group=1003. That worked fine with one exception. Anything that I
> copied to or saved to the directory turned out to be "F --- rw- rw- r--".

"File"?
"SetGID"?
"User read & write"?
"Group read & write"?
"Other read only"?

Yes? So? File permission bits aren't controlled by or inherited from the
directory permission bits. They are controlled by the create mode (from the
program that created the file) and the real user umask.

> So I went back to owner=1000 group=1000 and "D -G- rwx rwx r--" which
> seems to be working better except that now "world" has read access, when
> I really just want group=1003 to have read access.

Why did you do that? What did you expect to accomplish?

As far as I can tell, you replaced one group with another. Who can access
the directory and/or files changes, depending on who was in each of the two
groups. Everyone else has read access, just as they did with the earlier
setup.

> At least it prevents my effectively giving r/w access to group=1003 when
> I'm working stupid (ie, sleep-deprived, my usual state).

"prevents my effectively giving r/w access to group=1003" on what? The
directory? Or the files within the directory? Or both?

To prevent the group from having write access to the directory, remove the
group write access /on the directory/. This will prevent the group from
creating new files, or renaming or deleting old files from the directory.
IIUC, it should also prevent them from /extending/ or /truncating/ existing
files in the directory, although it *will not* prevent them from altering
the files inplace.

To prevent the group from having write access to the files, remove the group
write access /on each file/ in the directory. This will prevent the group
from altering the data in the file, including preventing inplace
alteration. This is /independent/ of the directory restrictions.

> So... someone (unruh?) said there was a way to make directory
> permissions fully hierarchical.

If there is a way, I'd like to know about it as well. Perhaps he was
thinking of Capabilities (see setcap(8) and getcap(8)) or Attributes (see
setfattr(1) chattr(1), etc) Both have abilities to restrict file access
beyond what the standard permission bits allow.

> I'm wondering if there's a trick I
> haven't tried, or if, although directory permissions can be made fully
> hierarchical the files within them are subject to access by those who
> know/guess their filespec.
>
> For a directory you want to be r/w for yourself, r/o to group, and
> inaccessible to others, what's the correct way to set it up?

chmod 0640 /path/to/directory
or
chmod u=rw,g=r,o= /path/to/directory

But, don't forget execute (search/cwd) access for the directory. What do you
want there?

--
Lew Pitcher
"In Skills, We Trust"

[Lew Pitcher]

On Tuesday 02 April 2013 16:51, in alt.os.linux, crank...@nomail.invalid
wrote:

> There is a directory that I want to be read/write for me, read/only for
> group, and inaccessible for others.
>
> I tried setting it up as "D -G- rwx r-x ---" with owner=1000 and
> group=1003. That worked fine with one exception. Anything that I
> copied to or saved to the directory turned out to be "F --- rw- rw- r--".

[snip]

> For a directory you want to be r/w for yourself, r/o to group, and
> inaccessible to others, what's the correct way to set it up?

Do this

1) Correct the ownership of the directory, and all it's files, so that all
are owned by user 1000, group 1003
chown -R 1000:1003 /path/to/directory

2) Correct the access rights to the directory, so that the owning user can
read directory, write/modify and search directory entries, the owning
group can read and search directory entries, and all others have no
access to the directory.
chmod u=rwx,g=rX,o= /path/to/directory

3) Correct the access rights to each file, so that the owning user can read
and write the file data, the owning group can only read the file data,
and all others have no access to the file data.
chmod u=rw,g=r,o= /path/to/directory/*
or
find /path/to/directory -type f -exec chmod u=rw,g=r,o= {} +

4) To ensure that new files get the proper permissions, set your umask to
037 /before/ creating files or manipulating additional files in the
directory.

[crankypuss]

On 04/02/2013 03:42 PM, Aragorn wrote:
> On Tuesday 02 April 2013 22:51, crankypuss conveyed the following to
> alt.os.linux...
>
>> There is a directory that I want to be read/write for me, read/only
>> for group, and inaccessible for others.
>>
>> I tried setting it up as "D -G- rwx r-x ---" with owner=1000 and
>> group=1003. That worked fine with one exception. Anything that I
>> copied to or saved to the directory turned out to be "F --- rw- rw-
>> r--".
>>
>> So I went back to owner=1000 group=1000 and "D -G- rwx rwx r--" which
>> seems to be working better except that now "world" has read access,
>> when I really just want group=1003 to have read access.
>>
>> At least it prevents my effectively giving r/w access to group=1003
>> when I'm working stupid (ie, sleep-deprived, my usual state).
>>
>> So... someone (unruh?) said there was a way to make directory
>> permissions fully hierarchical. I'm wondering if there's a trick I
>> haven't tried, or if, although directory permissions can be made fully
>> hierarchical the files within them are subject to access by those who
>> know/guess their filespec.
>>
>> For a directory you want to be r/w for yourself, r/o to group, and
>> inaccessible to others, what's the correct way to set it up?
>
> $ chmod 2750 $DIRECTORY

That's the first case mentioned above, "D -G- rwx r-x ---". Anything
the owner saves/copies there ends up with "rw-" for group, which is not
what I'm after. Thanks though.

[crankypuss]

On 04/02/2013 03:43 PM, Lew Pitcher wrote:
> On Tuesday 02 April 2013 16:51, in alt.os.linux, crank...@nomail.invalid
> wrote:
>
>> There is a directory that I want to be read/write for me, read/only for
>> group, and inaccessible for others.
>
> 1) chown the directory so that you are the user owner, and the appropriate
> group is the group owner
> 2) chmod the directory to 640, so that user gets read and write access, the
> group gets read access, and all others gets no access
>
> Note: you /might/ consider permit "execute" access on the directory for
> user, and possibly for group, as without it, you cant chdir into the
> directory. This would mean permissions of 740 or 750, depending.
>
>> I tried setting it up as "D -G- rwx r-x ---"
>
> Huh? I'm not familiar with this notation. My /guess/ is that
> - the "D" stands for directory,
> - the "-G-" stands for "SetGID permission",
> - the "rwx" stands for "User read, write, & execute permissions",
> - the "r-x" stands for "group read and execute permissions", and
> - the "---" stands for "other, no permissions".
>
> It would have been clearer if you just expressed the permissions as their
> octal number.

It might be clearer if I had used hex, octal is an archaic form of
notation for a 16-bit quantity. You managed to figure out the symbolic
notation used (basically what ls uses).

And another thing ought to be mentioned here is the concept of working
stupid. What I mean by "working stupid" is that one is sleep-deprived
to the point where bits are dropping, such as at the end of a
double-all-nighter, or working on many things at once and not able to
fully concentrate on a single one without interruption, etc. When
"working stupid" one needs all the detail-managing help he can get.

> So, you selected BSD semantics for the directory, so that
> - files created in the directory are assigned to the directory group owner
> - directories created in the directory will inherit the SetGID bit
>
>> with owner=1000 and
>> group=1003. That worked fine with one exception. Anything that I
>> copied to or saved to the directory turned out to be "F --- rw- rw- r--".
>
> "File"?
> "SetGID"?
> "User read & write"?
> "Group read & write"?
> "Other read only"?
>
> Yes? So?

So as mentioned, I don't want "group" rw or "other" anything, I want
group r-- other ---.

> File permission bits aren't controlled by or inherited from the
> directory permission bits. They are controlled by the create mode (from the
> program that created the file) and the real user umask.

Such is my understanding but imo the result is far from perfect.

>> So I went back to owner=1000 group=1000 and "D -G- rwx rwx r--" which
>> seems to be working better except that now "world" has read access, when
>> I really just want group=1003 to have read access.
>
> Why did you do that? What did you expect to accomplish?

It prevents others from being able to write the files, and world was
getting r/o access anyway; note gid change from 1003 to 1000, only owner
is 1000.

> As far as I can tell, you replaced one group with another. Who can access
> the directory and/or files changes, depending on who was in each of the two
> groups. Everyone else has read access, just as they did with the earlier
> setup.

Yes, but since group 1003 contained 3 users two of whom should not have
had r/w access this is an improvement.

>> At least it prevents my effectively giving r/w access to group=1003 when
>> I'm working stupid (ie, sleep-deprived, my usual state).
>
> "prevents my effectively giving r/w access to group=1003" on what? The
> directory? Or the files within the directory? Or both?

The files in the directory of course.

> To prevent the group from having write access to the directory, remove the
> group write access /on the directory/. This will prevent the group from
> creating new files, or renaming or deleting old files from the directory.
> IIUC, it should also prevent them from /extending/ or /truncating/ existing
> files in the directory, although it *will not* prevent them from altering
> the files inplace.

Yes, well, I don't want them fiddling the files at all.

> To prevent the group from having write access to the files, remove the group
> write access /on each file/ in the directory. This will prevent the group
> from altering the data in the file, including preventing inplace
> alteration. This is /independent/ of the directory restrictions.

Yes, and imo there's something very wrong about the fact that if I edit
a file and save it into that directory the group gets r/w access to it.

>> So... someone (unruh?) said there was a way to make directory
>> permissions fully hierarchical.
>
> If there is a way, I'd like to know about it as well. Perhaps he was
> thinking of Capabilities (see setcap(8) and getcap(8)) or Attributes (see
> setfattr(1) chattr(1), etc) Both have abilities to restrict file access
> beyond what the standard permission bits allow.
>
>> I'm wondering if there's a trick I
>> haven't tried, or if, although directory permissions can be made fully
>> hierarchical the files within them are subject to access by those who
>> know/guess their filespec.
>>
>> For a directory you want to be r/w for yourself, r/o to group, and
>> inaccessible to others, what's the correct way to set it up?
>
> chmod 0640 /path/to/directory
> or
> chmod u=rw,g=r,o= /path/to/directory
>
> But, don't forget execute (search/cwd) access for the directory. What do you
> want there?
>

I'm coming round to the opinion that the linux "group" concept is either
simply not what it implies, or malformed. To me, "group" means some
arbitrary collection of userids. However, linux filesystem semantics
seem to take "group" to mean some arbitrary collection of userids that
are to inherit shared write privileges. It seems that ogw might better
be ogwa (owner,group,world,aliens).

But there is much yet that I do not know about linux, hence the
question. Thanks.

[Richard Kettlewell]

crankypuss <crank...@nomail.invalid> writes:
> On 04/02/2013 03:43 PM, Lew Pitcher wrote:

>> It would have been clearer if you just expressed the permissions as
>> their octal number.
>
> It might be clearer if I had used hex, octal is an archaic form of
> notation for a 16-bit quantity. You managed to figure out the
> symbolic notation used (basically what ls uses).

Octal is used because permissions are structured as four groups of three
bits, which line up with the octal digits.

>> To prevent the group from having write access to the files, remove
>> the group write access /on each file/ in the directory. This will
>> prevent the group from altering the data in the file, including
>> preventing inplace alteration. This is /independent/ of the directory
>> restrictions.
>
> Yes, and imo there's something very wrong about the fact that if I
> edit a file and save it into that directory the group gets r/w access
> to it.

If you don’t want group write by default, set your umask accordingly.

--
http://www.greenend.org.uk/rjk/

[crankypuss]

On 04/02/2013 04:18 PM, Lew Pitcher wrote:

> 4) To ensure that new files get the proper permissions, set your umask to
> 037 /before/ creating files or manipulating additional files in the
> directory.

What is this "umask" and how does one set it to other than whatever the
default is? Nevermind I suppose, since I'm in the process of looking it up.

Looks like something else to set so that the user manually does part of
the job of the filesystem.

Somehow I am reminded of a Rube Goldberg device that actually does get
the coffee made and the eggs cooked. It becomes more and more clear
that the typical linux user is an administrator who is fairly bright,
farily young, and quite well-rested. Probably goes a ways toward
explaining much of the bitching and whining about Ubuntu, which is
supposedly slanted toward the former Windows user, such being basically
equivalent to someone who is is old and sleep-deprived and not very
bright to begin with.

If you don't get the humor there, well, explaining it would spoil the joke.

[crankypuss]

On 04/03/2013 03:06 AM, Richard Kettlewell wrote:
> crankypuss <crank...@nomail.invalid> writes:
>> On 04/02/2013 03:43 PM, Lew Pitcher wrote:
>
>>> It would have been clearer if you just expressed the permissions as
>>> their octal number.
>>
>> It might be clearer if I had used hex, octal is an archaic form of
>> notation for a 16-bit quantity. You managed to figure out the
>> symbolic notation used (basically what ls uses).
>
> Octal is used because permissions are structured as four groups of three
> bits, which line up with the octal digits.

Understood from the go.

>>> To prevent the group from having write access to the files, remove
>>> the group write access /on each file/ in the directory. This will
>>> prevent the group from altering the data in the file, including
>>> preventing inplace alteration. This is /independent/ of the directory
>>> restrictions.
>>
>> Yes, and imo there's something very wrong about the fact that if I
>> edit a file and save it into that directory the group gets r/w access
>> to it.
>
> If you don’t want group write by default, set your umask accordingly.
>

I just looked up the umask kludge. Fine if it's set properly, not what
I'd consider really reliable. Interesting that the SUID bit for
directories had no semantics a few years back, is that still broken?

Sorry for the sarcasm, old guys working in a state of perpetual sleep
deprivation have little patience with Rube-Goldbergian software. <g>

[Richard Kettlewell]

crankypuss <crank...@nomail.invalid> writes:
> On 04/03/2013 03:06 AM, Richard Kettlewell wrote:
>> crankypuss <crank...@nomail.invalid> writes:

>>> Yes, and imo there's something very wrong about the fact that if I
>>> edit a file and save it into that directory the group gets r/w access
>>> to it.
>>
>> If you don’t want group write by default, set your umask accordingly.
>
> I just looked up the umask kludge. Fine if it's set properly, not
> what I'd consider really reliable.

The operating system doesn’t know what policy you want for new files.
You have to tell it somehow.

--
http://www.greenend.org.uk/rjk/

[J G Miller]

On Wednesday, April 3rd, 2013, at 11:44:47h +0100, Richard Kettlewell wrote:

> The operating system doesn’t know what policy you want for new files.
> You have to tell it somehow.

Of course not, but the system administrator (or distribution packagers)
can set a sensible default in /etc/login.defs, which of course the user
may overrider in their own shell rc file.

[Lew Pitcher]

On Tuesday 02 April 2013 18:18, in alt.os.linux, lpit...@teksavvy.com
wrote:

Also, set /your/ effective group to group 1003 /before/ creating or
manipulating files in the directory. To do this, use the newgrp(1) or sg(1)
commands. Caveat: you must already belong to group 1003 in addition to your
regular group before you can newgrp(1) or sg(1).

[Lew Pitcher]

On Wednesday 03 April 2013 05:08, in alt.os.linux, crank...@nomail.invalid
wrote:

> On 04/02/2013 04:18 PM, Lew Pitcher wrote:
>
>> 4) To ensure that new files get the proper permissions, set your umask to
>> 037 /before/ creating files or manipulating additional files in the
>> directory.
>
> What is this "umask"

Here, let me google that for you: http://www.lmgtfy.com/?q=umask

> and how does one set it to other than whatever the
> default is?

The umask builtin command in your shell does that for you.

> Nevermind I suppose, since I'm in the process of looking it
> up.

> Looks like something else to set so that the user manually does part of
> the job of the filesystem.

Nope. It's a fine-grained user control /over/ the filesystem.

[snip]

[J G Miller]

On Wednesday, April 3rd, 2013, at 08:51:09h -0400, Lew Pitcher wrote:

> Also, set /your/ effective group to group 1003 /before/ creating or
> manipulating files in the directory.

Or for convenience make the directory set group id (with possible
security consideration)?

chmod g+s directory_name

[unruh]

On 2013-04-03, crankypuss <crank...@nomail.invalid> wrote:
> On 04/02/2013 04:18 PM, Lew Pitcher wrote:
>
>> 4) To ensure that new files get the proper permissions, set your umask to
>> 037 /before/ creating files or manipulating additional files in the
>> directory.
>
> What is this "umask" and how does one set it to other than whatever the
> default is? Nevermind I suppose, since I'm in the process of looking it up.
>
> Looks like something else to set so that the user manually does part of
> the job of the filesystem.
>
> Somehow I am reminded of a Rube Goldberg device that actually does get

Just because you are ignorant does not mean that what has been done is
"Rube goldberg". Something has to tell the system what permissions you
want be default on FILES. Remember that directory permissions are
different from file permissions. They do different things, so having
files inherit directory permissions would be silly. Teh w permssion on a
directory means that someone can erase filenames or add filenames to the
directory. the w on a file means that people can alter the contents of
the file. Just because you want to let people not erase files, does not
mean that you also do not want them to alter files in that directory.

> the coffee made and the eggs cooked. It becomes more and more clear
> that the typical linux user is an administrator who is fairly bright,
> farily young, and quite well-rested. Probably goes a ways toward

???? Defaults are for setting up when you ARE well rested, or for
changing after you discover that they do not work.

Unfotunately changing ignorance is also something that works best when
you are well rested.

[crankypuss]

On 04/03/2013 04:44 AM, Richard Kettlewell wrote:
> crankypuss <crank...@nomail.invalid> writes:
>> On 04/03/2013 03:06 AM, Richard Kettlewell wrote:
>>> crankypuss <crank...@nomail.invalid> writes:
>
>>>> Yes, and imo there's something very wrong about the fact that if I
>>>> edit a file and save it into that directory the group gets r/w access
>>>> to it.
>>>
>>> If you don’t want group write by default, set your umask accordingly.
>>
>> I just looked up the umask kludge. Fine if it's set properly, not
>> what I'd consider really reliable.
>
> The operating system doesn’t know what policy you want for new files.
> You have to tell it somehow.
>

Okay, how about if I set the (unused) SUID bit in the directory and let
the operating system apply the directory permissions as a last-ditch
umask, ay? I'm all for flexibility, but at the moment linux seems to
lack that little bit of flexibility that would readily allow the level
of control that prevents certain security exposures.

When I do "man umask" what I find is the subroutine call, apparently
"dumb users" aren't supposed to change it; go figure.

[crankypuss]

More information about how that is done, pray tell?

The thing about linux is that the system is very good and the
documentation is very bad. I suppose that's what one should expect from
an ad-hoc system built as a free version of an ad-hoc system, but maybe
one of these days we'll get around to fixing it to be somewhat less
lore-intensive. And yes, I'm working on things rather than just
bellyaching, but my physical body is strangely limited to a
single-thread existence.

[crankypuss]

On 04/03/2013 06:54 AM, Lew Pitcher wrote:
> On Wednesday 03 April 2013 05:08, in alt.os.linux, crank...@nomail.invalid
> wrote:
>
>> On 04/02/2013 04:18 PM, Lew Pitcher wrote:
>>
>>> 4) To ensure that new files get the proper permissions, set your umask to
>>> 037 /before/ creating files or manipulating additional files in the
>>> directory.
>>
>> What is this "umask"
>
> Here, let me google that for you: http://www.lmgtfy.com/?q=umask
>
>> and how does one set it to other than whatever the
>> default is?
>
> The umask builtin command in your shell does that for you.

Frigging shells, I've yet to see one that would even make a good boat
anchor.

>> Nevermind I suppose, since I'm in the process of looking it
>> up.
>
>> Looks like something else to set so that the user manually does part of
>> the job of the filesystem.
>
> Nope. It's a fine-grained user control /over/ the filesystem.
>
> [snip]
>

Ahem. Thanks.

[crankypuss]

On 04/03/2013 09:33 AM, unruh wrote:
> On 2013-04-03, crankypuss <crank...@nomail.invalid> wrote:
>> On 04/02/2013 04:18 PM, Lew Pitcher wrote:
>>
>>> 4) To ensure that new files get the proper permissions, set your umask to
>>> 037 /before/ creating files or manipulating additional files in the
>>> directory.
>>
>> What is this "umask" and how does one set it to other than whatever the
>> default is? Nevermind I suppose, since I'm in the process of looking it up.
>>
>> Looks like something else to set so that the user manually does part of
>> the job of the filesystem.
>>
>> Somehow I am reminded of a Rube Goldberg device that actually does get
>
> Just because you are ignorant does not mean that what has been done is
> "Rube goldberg". Something has to tell the system what permissions you
> want be default on FILES. Remember that directory permissions are
> different from file permissions. They do different things, so having
> files inherit directory permissions would be silly. Teh w permssion on a
> directory means that someone can erase filenames or add filenames to the
> directory. the w on a file means that people can alter the contents of
> the file. Just because you want to let people not erase files, does not
> mean that you also do not want them to alter files in that directory.

Interesting that the SUID bit has no semantics with regard to directories.

>> the coffee made and the eggs cooked. It becomes more and more clear
>> that the typical linux user is an administrator who is fairly bright,
>> farily young, and quite well-rested. Probably goes a ways toward
>
> ???? Defaults are for setting up when you ARE well rested, or for
> changing after you discover that they do not work.
>
> Unfotunately changing ignorance is also something that works best when
> you are well rested.

No offense, but people who require the "well rested" attribute in order
to change reality are similar to those who develop software on extremely
fast computers... when working in other situations their efforts
generally fall on their face.

[Aragorn]

On Wednesday 03 April 2013 10:24, crankypuss conveyed the following to

Then you should look into the umask settings for the owner. Some
distributions set the default umask for unprivileged users to 002, and
it sounds like that is the case for the user account who writes to that
directory on your system.

On my own system, I use 077 for my user accounts, and 022 for root.

[Aragorn]

On Wednesday 03 April 2013 19:43, crankypuss conveyed the following to
alt.os.linux...

umask is a Bash built-in, so if you issue...

$ man umask

... you get to see the Bash man page instead. In it, hit "/" and type
"umask", and it'll take you to the appropriate section. ;-)

[J G Miller]

On Wednesday, April 3rd, 2013, at 11:47:14h -0600, CrankyPuss wrote:

> More information about how that is done, pray tell?

Fire up a "root" terminal (ie the user is root),
then as root

cd /etc

The with the editor of your choice (in these circumstances
vi is the best for speed)

/UMASK (that is the vi command to search for a string)

which will take you to the line with UMASK eg

UMASK 077

Then change the value to the default you so desire for all users.

> The thing about linux is that the system is very good and the
> documentation is very bad.

No the documentation is not very bad. There is some very good
documentation and there are lots of things which are poorly documented.

For the basics of the command line, get a copy of Unix for the Impatient.

For how to do things, look at the HOWTO documents but be warned that
aspects of these, the information is dated (most specifically
kernel version 2.4 specifics) and sadly nobody has bothered
to update them.

For more recent software two of the best sources of in depth "tips and tricks"
are Archi Wiki pages and Gentoo documentation.

Ubuntu also has community pages on various applications which are good
as a beginners guide but are only GUI specific to doing tasks, but even
so can be helpful as a gentle introduction to get a feel of what is
available (eg vnc which has many different applications and is quite
confusing, viz what is the difference between vino and vinaigre?).

> I suppose that's what one should expect from
> an ad-hoc system built as a free version of an ad-hoc system

If you want less ad-hocness and more authoritarian style, try openBSD
instead, but you will not get the multitude of possibilities as with
GNU/Linux.

> one of these days we'll get around to fixing it to be somewhat less
> lore-intensive.

By the time you have fixed it, the world will have moved on.

<speculative mode>

If current trends continue, most people will be using Android,
and probably Mark Shuttleworth will have arrived too late at
the party to make any significant difference.

</speculative mode>

[J G Miller]

On Wednesday, April 3rd, 2013, at 11:43:17h -0600, Cranky Puss wrote:

> I'm all for flexibility, but at the moment linux seems to
> lack that little bit of flexibility that would readily allow the level
> of control that prevents certain security exposures.

I am sorry but this is just nonsense.

For finer grain control of who can access directories and
files there is the ACL method.

And per application access can be implemented with apparmor.

[J G Miller]

On Wednesday, April 3rd, 2013, at 11:51:30h -0600, Cranky Puss claimed:

> Interesting that the SUID bit has no semantics with regard to directories.

Yes it does.

One can make a directory SUID for the ownership of files (and subdirectories)
in the directory.

And then there is SGID for the group aspect.

> No offense, but people who require the "well rested" attribute in order
> to change reality are similar to those who develop software on extremely
> fast computers...

Very true -- people who are not "well rested" have changed reality by
blowing themselves up. It is highly probable that the people who
were responsible for the disaster at Chernobyl were not well rested.

According to

<http://www.lafuel.COM/2013/01/Chernobyl-and-other-disasters-caused-by-tired-workers&d=78>

QUOTE

The reactor meltdown was caused by a series of tests run by an overworked
and tired crew, in the middle of the night. When problems arose they weren’t
able to concentrate properly, they were confused, and their automatic
behavior led to the catastrophe.

...

Night shift operators at 4 in the morning caused another big nuclear
plant accident – the 1979 meltdown at the Three Mile Island nuclear
generator in Pennsylvania.

Experts agreed that fatigue was one of the contributing factors.

UNQUOTE

[Bit Twister]

On Wed, 03 Apr 2013 11:51:30 -0600, crankypuss wrote:

You know, it is pretty sad that you have to go to another Usenet group
to get answers to your question because the users of your distribution group
have allowed the trolls to drive off subject matter experts.

Now what is worse, you have spent so much time reading and playing
with the trolls, you are becoming one.

You sound just like the letter spaced one with a different name.

Think I am wrong, read your responses to people trying to help you in
this thread.

> Frigging shells, I've yet to see one that would even make a good boat
> anchor.

> More information about how that is done, pray tell?

> The thing about linux is that the system is very good and the

> documentation is very bad. I suppose that's what one should expect from
> an ad-hoc system built as a free version of an ad-hoc system, but maybe

> one of these days we'll get around to fixing it to be somewhat less

> lore-intensive. And yes, I'm working on things rather than just
> bellyaching, but my physical body is strangely limited to a
> single-thread existence.

> I'm all for flexibility, but at the moment linux seems to
> lack that little bit of flexibility that would readily allow the level
> of control that prevents certain security exposures.

> No offense, but people who require the "well rested" attribute in order
> to change reality are similar to those who develop software on extremely
> fast computers... when working in other situations their efforts
> generally fall on their face.

> When I do "man umask" what I find is the subroutine call, apparently
> "dumb users" aren't supposed to change it; go figure.

Just curious, just what operating system and shell is so damn much
better and more secure?

As for documentation, there is http://tldp.org

For the newbie lurkers,
http://tldp.org/LDP/sag/html/sag.html
http://tldp.org/LDP/nag2/index.html
will provide a reasonable overview.

Best real time documentation I have found is in the man pages and the
configuration files like .conf or .def. Fallback is look at the
application script I am trying to configure.

Of course picking a distribution can have a great effect on what
documentation is available. 8-)

The "locate" command can be helpful. example

locate -i login
might return a few lines. Since the sag doc says /etc is the starting place for
system stuff, I would use

locate -i login | grep /etc
/etc/login.defs looks interesting

Need a command, there is apropos key_word_here or man -k key_word_here, example

apropos login

man login also suggests /etc/login.defs as a configuration file used
in the login session setup.

Does not hurt to run the "man man" command. :)

[Jasen Betts]

On 2013-04-03, crankypuss <crank...@nomail.invalid> wrote:

> When I do "man umask" what I find is the subroutine call, apparently
> "dumb users" aren't supposed to change it;

It's a built-in, we discussed this a couple of months back.

--
⚂⚃ 100% natural

[crankypuss]

Several posters have mentioned umask. None seem to care what might
happen if a malfunctioning script sets it to 0. It isn't that I have
anything against the concept of umask, but imo there ought to be a
method of letting the directory permissions maximize the permission
levels of whatever is stored within the directory. From the perspective
of managing information security, what is implemented seems inadequate.

[crankypuss]

Thanks.

[crankypuss]

On 04/03/2013 02:14 PM, J G Miller wrote:
> On Wednesday, April 3rd, 2013, at 11:51:30h -0600, Cranky Puss claimed:
>
>> Interesting that the SUID bit has no semantics with regard to directories.
>
> Yes it does.
>
> One can make a directory SUID for the ownership of files (and subdirectories)
> in the directory.

From Linux Application Development [Michael K. Johnson & Eric W. Troan,
Addison Wesley, 1998] 10.1.2 "File Permission Modifiers", pg 147

"The setuid bit actually has no semantics
when it is set on a directory."

Granted 1998 is a bit dated for Linux, but then there is this, from
http://en.wikipedia.org/wiki/Setuid#setuid_and_setgid_on_directories

"The setuid permission set on a directory is ignored
on UNIX and Linux systems."

So, what is this support for SUID on directories that you allude to?

> And then there is SGID for the group aspect.

I'm aware of SGID, which can be quite useful; thanks.

>> No offense, but people who require the "well rested" attribute in order
>> to change reality are similar to those who develop software on extremely
>> fast computers...
>
> Very true -- people who are not "well rested" have changed reality by
> blowing themselves up. It is highly probable that the people who
> were responsible for the disaster at Chernobyl were not well rested.

That is why software ought not demand that people be well-rested in
order to avoid making those "working stupid" errors that while being
subtle enough to miss when tired can cause significant issues.

This is one of the reasons that I consider sed and bash in general to be
abominations and C not much better; the leverage applied by a
one-character typing error can have results that are far too great imo.

Mileage obviously varies, some people think that software developers
should have the fastest possible computers so the most can be gained
from the efforts of the developer; I contend that those who develop
system-level software, especially software tools, code that will be run
more than most anything else, should use slow computers, or at least
they should have slow computers available for all testing so that
performance issues come to the top and get fixed instead of going into
the field. Numerous one-character options are a similar category of
error-encouragers. The lack of control over permission levels that I
have been pointing out in this thread is another such issue, one that is
imo a clear security hole.

[crankypuss]

Thank you for your opinion.

[Jasen Betts]

On 2013-04-04, crankypuss <crank...@nomail.invalid> wrote:
>
> Several posters have mentioned umask. None seem to care what might
> happen if a malfunctioning script sets it to 0.

The malfunctioning script and any processes it launches would create
world writable files. that doesn't seem particularly bad.

--
⚂⚃ 100% natural

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[Richard Kettlewell]

Jasen Betts <ja...@xnet.co.nz> writes:
> crankypuss <crank...@nomail.invalid> wrote:

>> Several posters have mentioned umask. None seem to care what might
>> happen if a malfunctioning script sets it to 0.
>
> The malfunctioning script and any processes it launches would create
> world writable files. that doesn't seem particularly bad.

That depends on the environment you’re in and what you’re going to do
with the files next. But a “malfunctioning” script could do any of a
million other stupid things too, and in practice “sets umask 0 for no
good reason” doesn’t appear to be an especially common bug.

--
http://www.greenend.org.uk/rjk/

[crankypuss]

On 04/04/2013 02:29 AM, Jasen Betts wrote:
> On 2013-04-04, crankypuss <crank...@nomail.invalid> wrote:
>>
>> Several posters have mentioned umask. None seem to care what might
>> happen if a malfunctioning script sets it to 0.
>
> The malfunctioning script and any processes it launches would create
> world writable files. that doesn't seem particularly bad.
>

Especially when the application is processing payroll, correct? Or
defining some company policy? Then any bozo can go in and edit it to
his taste.

World-writable files are *usually* bad unless they are in /tmp or
equivalent.

[Lew Pitcher]

On Thursday 04 April 2013 04:29, in alt.os.linux, ja...@xnet.co.nz wrote:

> On 2013-04-04, crankypuss <crank...@nomail.invalid> wrote:
>>
>> Several posters have mentioned umask. None seem to care what might
>> happen if a malfunctioning script sets it to 0.
>
> The malfunctioning script and any processes it launches would create
> world writable files.

Not really, but almost.

The umask removes permissions /if they were set/: for every '1' bit in the
umask, the corresponding permission bit is forcibly set to '0'. *BUT*, for
every '0' bit in the umask, the corresponding permission bit is *left as
the creating program set it*.

It is up to the creating program (as part of it's program code) to
select /which/ permission bits are set before the umask unsets them.
/IF/ the program uses a mode that sets the write bit for user, group & other
creat("newfile",0666)
then the file would be (sans umask) "world readable".

*BUT*, the program doesn't have to do that. It could just as easily set the
permission bits so that only the creating user has access
creat("newfile",0600)
in which case, a umask of 0 /would not/ "give back" any group or other
permissions.

> that doesn't seem particularly bad.

A umask of 0 leaves the file /as the program and programmer/ intended it.
Hopefully, the programmer did the "right thing"; they often do.

[Aragorn]

On Thursday 04 April 2013 09:44, crankypuss conveyed the following to

alt.os.linux...

> On 04/03/2013 12:16 PM, Aragorn wrote:
>
>> On Wednesday 03 April 2013 10:24, crankypuss conveyed the following
>> to alt.os.linux...
>>
>>> On 04/02/2013 03:42 PM, Aragorn wrote:
>>>
>>>> On Tuesday 02 April 2013 22:51, crankypuss conveyed the following
>>>> to alt.os.linux...
>>>>

>>>>> [...]

>>>>> For a directory you want to be r/w for yourself, r/o to group, and
>>>>> inaccessible to others, what's the correct way to set it up?
>>>>
>>>> $ chmod 2750 $DIRECTORY
>>>
>>> That's the first case mentioned above, "D -G- rwx r-x ---".
>>> Anything the owner saves/copies there ends up with "rw-" for group,
>>> which is not what I'm after. Thanks though.
>>
>> Then you should look into the umask settings for the owner. Some
>> distributions set the default umask for unprivileged users to 002,
>> and it sounds like that is the case for the user account who writes
>> to that directory on your system.
>>
>> On my own system, I use 077 for my user accounts, and 022 for root.
>
> Several posters have mentioned umask. None seem to care what might
> happen if a malfunctioning script sets it to 0.

Then this would only take effect within the script itself, not outside
of it. Scripts are by definition executed in a subshell. :-)

> It isn't that I have anything against the concept of umask, but imo
> there ought to be a method of letting the directory permissions
> maximize the permission levels of whatever is stored within the
> directory.

Apples and oranges.

> From the perspective of managing information security, what is
> implemented seems inadequate.

Well, if the POSIX permissions are not sufficient for your intended
project, then there's always ACLs. ;-)

[crankypuss]

So, what, scripts executed in a subshell can do no damage? Not an
excuse, buddy.

>> It isn't that I have anything against the concept of umask, but imo
>> there ought to be a method of letting the directory permissions
>> maximize the permission levels of whatever is stored within the
>> directory.
>
> Apples and oranges.

One logical AND is different from another, eh? I consider it otherwise.

>> From the perspective of managing information security, what is
>> implemented seems inadequate.
>
> Well, if the POSIX permissions are not sufficient for your intended
> project, then there's always ACLs. ;-)
>

There's always another kludge, right?

Sorry, linux is the victim of rampant feature-creep, which is to be
expected since it's always easier to just add one-more-flag, especially
when the world is based on scripts that expect rigidly unchanging output.

Whatever; I think the question asked in the original post has been
sufficiently answered, and I thank everyone who replied.

[Aragorn]

On Saturday 06 April 2013 11:10, crankypuss conveyed the following to
alt.os.linux...

> On 04/05/2013 01:05 PM, Aragorn wrote:
>
>> Then this would only take effect within the script itself, not
>> outside of it. Scripts are by definition executed in a subshell. :-)
>
> So, what, scripts executed in a subshell can do no damage? Not an
> excuse, buddy.

A script running in a subshell cannot change the environment of its
parent, so when the script terminates, its environment gets destroyed.

>>> It isn't that I have anything against the concept of umask, but imo
>>> there ought to be a method of letting the directory permissions
>>> maximize the permission levels of whatever is stored within the
>>> directory.
>>
>> Apples and oranges.
>
> One logical AND is different from another, eh? I consider it
> otherwise.

Then you consider it wrong, and a logical "and" has nothing to do with
it. Directories have permissions and files have permissions, and what a
particular user on the system can do to/with a file depends on _both_
those permissions sets, as well as on whether said user is the owner, a
member of the group, or "an other". And then we're not even talking of
special file/directory attributes - see...

$ man chattr

All of it works together, but there is no single rule which dictates the
permissions or ownership for everything.

>>> From the perspective of managing information security, what is
>>> implemented seems inadequate.
>>
>> Well, if the POSIX permissions are not sufficient for your intended
>> project, then there's always ACLs. ;-)
>
> There's always another kludge, right?

ACLs were required by - I believe - the US Department of Defense in
order for an operating system to be qualified as trustworthy enough for
high security implementation. This is how ACLs became included in the
POSIX standard, and as GNU/Linux aims for POSIX and SUS compatibility,
it has adopted ACL support.

Strictly speaking however, UNIX doesn't need ACLs - unlike VMS, from
which the NT kernel of the modern versions of Microsoft Windows are
derived - because it already has its own security system built-in.

> Sorry, linux is the victim of rampant feature-creep, which is to be
> expected since it's always easier to just add one-more-flag,
> especially when the world is based on scripts that expect rigidly
> unchanging output.

I wouldn't call it feature creep when we're talking of the base
structure of the operating system.

When we're talking of introducing Windows-/Mac-like behavior such as
automounting of removable storage devices, graphical boot splash screens
et al, then, yes, I would agree with that.

You can blame the Windows indoctrination of the latest generation of
FLOSS developers for that. The earlier generations of FLOSS developers
were mainly UNIX people, and their minds were not poisoned by The
Microsoft Way (tm). But the newer generation, they all grew up with
Windows, and it has badly influenced them and deprived them of some of
their common sense.

[crankypuss]

On 04/06/2013 07:26 AM, Aragorn wrote:
> On Saturday 06 April 2013 11:10, crankypuss conveyed the following to
> alt.os.linux...
>
>> On 04/05/2013 01:05 PM, Aragorn wrote:
>>
>>> Then this would only take effect within the script itself, not
>>> outside of it. Scripts are by definition executed in a subshell. :-)
>>
>> So, what, scripts executed in a subshell can do no damage? Not an
>> excuse, buddy.
>
> A script running in a subshell cannot change the environment of its
> parent, so when the script terminates, its environment gets destroyed.

But none of the files it has munged into becoming security exposures go
away with it.

>>>> It isn't that I have anything against the concept of umask, but imo
>>>> there ought to be a method of letting the directory permissions
>>>> maximize the permission levels of whatever is stored within the
>>>> directory.
>>>
>>> Apples and oranges.
>>
>> One logical AND is different from another, eh? I consider it
>> otherwise.
>
> Then you consider it wrong, and a logical "and" has nothing to do with
> it. Directories have permissions and files have permissions, and what a
> particular user on the system can do to/with a file depends on _both_
> those permissions sets, as well as on whether said user is the owner, a
> member of the group, or "an other". And then we're not even talking of
> special file/directory attributes - see...
>
> $ man chattr
>
> All of it works together, but there is no single rule which dictates the
> permissions or ownership for everything.

If you were to set something like the SUID bit in directory permissions
and define that to mean that the directory permissions are logically
AND'ed with the result of umask, the problem I've been referring to
would disappear. A directory could easily be set up to dictate the
maximum permissions, but would not have to be set up that way.

>>>> From the perspective of managing information security, what is
>>>> implemented seems inadequate.
>>>
>>> Well, if the POSIX permissions are not sufficient for your intended
>>> project, then there's always ACLs. ;-)
>>
>> There's always another kludge, right?
>
> ACLs were required by - I believe - the US Department of Defense in
> order for an operating system to be qualified as trustworthy enough for
> high security implementation.

Governments can screw up anything.

> This is how ACLs became included in the
> POSIX standard, and as GNU/Linux aims for POSIX and SUS compatibility,
> it has adopted ACL support.
>
> Strictly speaking however, UNIX doesn't need ACLs - unlike VMS, from
> which the NT kernel of the modern versions of Microsoft Windows are
> derived - because it already has its own security system built-in.
>
>> Sorry, linux is the victim of rampant feature-creep, which is to be
>> expected since it's always easier to just add one-more-flag,
>> especially when the world is based on scripts that expect rigidly
>> unchanging output.
>
> I wouldn't call it feature creep when we're talking of the base
> structure of the operating system.

Philosophically speaking, is the kernel alone the "operating system" or
do the core-commands also get included? I'd say that the "operating
system" contains both the kernel and the core-commands. Others might
see it differently, but the minute they start using an "operating
system" that consists of nothing but the kernel, they've begun writing
their own set of core-commands.

> When we're talking of introducing Windows-/Mac-like behavior such as
> automounting of removable storage devices, graphical boot splash screens
> et al, then, yes, I would agree with that.
>
> You can blame the Windows indoctrination of the latest generation of
> FLOSS developers for that. The earlier generations of FLOSS developers
> were mainly UNIX people, and their minds were not poisoned by The
> Microsoft Way (tm). But the newer generation, they all grew up with
> Windows, and it has badly influenced them and deprived them of some of
> their common sense.
>

Drag-and-drop is a joke unless file permissions are specified at least
in part by the receiving directories. Linux "groups" are pretty clearly
intended for small groups of people working cooperatively, rather than
groups who might be permitted to read certain information but never
modify it. imo of course. And gnome2 is pretty lame. Also imo.

Just because linux is a couple of orders of magnitude better than
MS-Windows doesn't mean it's perfect. And it's not an excuse to shrug
and add yet-another-flag to tar or rsync or whatever. But people seem
intent on taking those routes. Humans, go figure.

I do agree that the latest generation of FLOSS programmers seem to be
trying to make linux into a Mac/Windows burger and doing a halfassed job
of it.

[Aragorn]

On Saturday 06 April 2013 21:01, crankypuss conveyed the following to

alt.os.linux...

> On 04/06/2013 07:26 AM, Aragorn wrote:
>
>> On Saturday 06 April 2013 11:10, crankypuss conveyed the following to
>> alt.os.linux...
>>
>>> On 04/05/2013 01:05 PM, Aragorn wrote:
>>>
>>>> Then this would only take effect within the script itself, not
>>>> outside of it. Scripts are by definition executed in a subshell.
>>>> :-)
>>>
>>> So, what, scripts executed in a subshell can do no damage? Not an
>>> excuse, buddy.
>>
>> A script running in a subshell cannot change the environment of its
>> parent, so when the script terminates, its environment gets
>> destroyed.
>
> But none of the files it has munged into becoming security exposures
> go away with it.

That is true, but a script is human-readable, so a responsible user
would always look at what the script does before running it.

In addition to that, there isn't so much of a security issue - albeit
that there may be a _privacy_ issue - when the script is executed by an
unprivileged user account.

>>> Sorry, linux is the victim of rampant feature-creep, which is to be
>>> expected since it's always easier to just add one-more-flag,
>>> especially when the world is based on scripts that expect rigidly
>>> unchanging output.
>>
>> I wouldn't call it feature creep when we're talking of the base
>> structure of the operating system.
>
> Philosophically speaking, is the kernel alone the "operating system"
> or do the core-commands also get included?

This is a matter of some hot debate and controversy.

> I'd say that the "operating system" contains both the kernel and the
> core-commands.

That is also how I see it, and why I refer to the whole operating system
as GNU/Linux. Linux is the kernel, and the userland utilities,
libraries and toolchain needed in order to make the system Touring-
complete - and thus a real operating system - all come from GNU. The
rest of the stuff is add-on software and may have different licenses.

> Others might see it differently, but the minute they start using an
> "operating system" that consists of nothing but the kernel, they've
> begun writing their own set of core-commands.

Android springs to mind. It's got a Linux kernel, but the userland is
all made up of non-GNU stuff. And then there are also the embedded
Linux devices of course.

>> When we're talking of introducing Windows-/Mac-like behavior such as
>> automounting of removable storage devices, graphical boot splash
>> screens et al, then, yes, I would agree with that.
>>
>> You can blame the Windows indoctrination of the latest generation of
>> FLOSS developers for that. The earlier generations of FLOSS
>> developers were mainly UNIX people, and their minds were not poisoned
>> by The Microsoft Way (tm). But the newer generation, they all grew
>> up with Windows, and it has badly influenced them and deprived them
>> of some of their common sense.
>
> Drag-and-drop is a joke unless file permissions are specified at least
> in part by the receiving directories.

"In part", they are. The target directory's permissions do also specify
to a certain extent what may and may not be done with/to a file.
However, the source file's permissions mask does not change, unless
certain command line options are passed to the copy process. But then
we're not talking of drag & drop anymore, of course.

> Linux "groups" are pretty clearly intended for small groups of people
> working cooperatively, rather than groups who might be permitted to
> read certain information but never modify it.

No, that is a false assumption, but if your /etc/login.defs file
specifies a permissive umask for the group if the group's ID and name
are the same as that of the owner, then I can understand why you would
come to such a conclusion.

If I understand correctly, then it was RedHat who introduced the habit
of having the primary group for a newly created user account be of the
same ID and name as that user account. Other distributions - mainly the
RPM-based ones, of course - soon took over that habit. However, the
custom used to be that a newly created user account was simply a member
of the group "users" and that the default umask would be either 027 or
077.

> imo of course. And gnome2 is pretty lame. Also imo.

I've never really liked GNOME. I do however like KDE, because of its
high degree of customizability and its well-polished look & feel.

> Just because linux is a couple of orders of magnitude better than
> MS-Windows doesn't mean it's perfect.

Is anything ever perfect?

--

[Aragorn]

On Saturday 06 April 2013 21:20, Aragorn conveyed the following to
alt.os.linux...

> [...] Linux is the kernel, and the userland utilities,libraries and
> toolchain needed in order to make the system Touring-complete [...]
^^^^^^^^^^^^^^^^

That should be "Turing-complete", of course.

[Richard Kettlewell]

Aragorn <str...@telenet.be.invalid> writes:
> If I understand correctly, then it was RedHat who introduced the habit
> of having the primary group for a newly created user account be of the
> same ID and name as that user account.

I don’t think it’s original to RH, it was a standard way of doing things
when I first encountered Unix.

--
http://www.greenend.org.uk/rjk/

[Richard Kettlewell]

crankypuss <crank...@nomail.invalid> writes:
> the problem I've been referring to

Is a nonissue compared to bugs that *actually happen in real life*.
Get a grip.

--
http://www.greenend.org.uk/rjk/

[crankypuss]

On 04/06/2013 02:43 PM, Richard Kettlewell wrote:
> crankypuss <crank...@nomail.invalid> writes:
>> the problem I've been referring to
>
> Is a nonissue compared to bugs that *actually happen in real life*.
> Get a grip.
>

Hey, I found out about it "in real life".

[Jasen Betts]

On 2013-04-06, crankypuss <crank...@nomail.invalid> wrote:
> On 04/06/2013 07:26 AM, Aragorn wrote:
>> On Saturday 06 April 2013 11:10, crankypuss conveyed the following to
>> alt.os.linux...
>>
>>> On 04/05/2013 01:05 PM, Aragorn wrote:
>>>
>>>> Then this would only take effect within the script itself, not
>>>> outside of it. Scripts are by definition executed in a subshell. :-)
>>>
>>> So, what, scripts executed in a subshell can do no damage? Not an
>>> excuse, buddy.
>>
>> A script running in a subshell cannot change the environment of its
>> parent, so when the script terminates, its environment gets destroyed.
>
> But none of the files it has munged into becoming security exposures go
> away with it.

Yeah, if you screw up bad stuff happens.

Why is that a problem?

[J G Miller]

On Saturday, April 6th, 2013, at 21:24:54h +0000,
Jasen Betts asked:

> Yeah, if you screw up bad stuff happens.
>
> Why is that a problem?

You obivously have a good team of lawyers to ensure
that you are not responsible because of the small print
clause "no matter what happens, it is not our fault"
in the contract.

Come to think of it, that is exactly what it says in the GPL ;)

QUOTE

THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE
OF THE PROGRAM IS WITH YOU.

SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE
COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

UNQUOTE

[crankypuss]

On 04/06/2013 03:24 PM, Jasen Betts wrote:
> On 2013-04-06, crankypuss <crank...@nomail.invalid> wrote:
>> On 04/06/2013 07:26 AM, Aragorn wrote:
>>> On Saturday 06 April 2013 11:10, crankypuss conveyed the following to
>>> alt.os.linux...
>>>
>>>> On 04/05/2013 01:05 PM, Aragorn wrote:
>>>>
>>>>> Then this would only take effect within the script itself, not
>>>>> outside of it. Scripts are by definition executed in a subshell. :-)
>>>>
>>>> So, what, scripts executed in a subshell can do no damage? Not an
>>>> excuse, buddy.
>>>
>>> A script running in a subshell cannot change the environment of its
>>> parent, so when the script terminates, its environment gets destroyed.
>>
>> But none of the files it has munged into becoming security exposures go
>> away with it.
>
> Yeah, if you screw up bad stuff happens.
>
> Why is that a problem?
>

Apparently other people never screw up. I used to believe that about
myself but events proved me wrong. I'm usually sleep-deprived and doing
half a dozen things at once, so I prefer software not to put things on
the floor because I *will* trip over those. What I consider "good
software" makes you intentionally take the safety off when the gun is
pointed at your foot. Slopware don't much care what happens, and fools
think that is cute, for a while; then eventually we get tired of limping
and avoid slopware, it's just part of growing old and stupid.

[Richard Kettlewell]

Have a look in the CVE database. Maybe four or five instances out of
over 60,000 security advisories. You’re making a mountain out of a
molehill.

--
http://www.greenend.org.uk/rjk/

[crankypuss]

On 04/07/2013 03:25 AM, Richard Kettlewell wrote:
> crankypuss <crank...@nomail.invalid> writes:
>> Richard Kettlewell wrote:
>>> crankypuss <crank...@nomail.invalid> writes:
>>>> the problem I've been referring to
>>>
>>> Is a nonissue compared to bugs that *actually happen in real life*.
>>> Get a grip.
>>
>> Hey, I found out about it "in real life".
>
> Have a look in the CVE database. Maybe four or five instances out of
> over 60,000 security advisories. You’re making a mountain out of a
> molehill.

It is a molehill for those administering servers since of course only
the most basic issues belong to them and anything else is a user error.

Now you may choose, between continuing to preach to me about how trivial
this is, or you may accept that I have found it to be a pain in the ass,
and STFU about it.

Thank you for your opinion, I place appropriate value on it. We seem to
grasp the same understanding of the technical issues, which I consider
sufficient.

[dx...@albury.nospam.net.au]

crankypuss wrote:
> On 04/06/2013 03:24 PM, Jasen Betts wrote:

<Snip>

>> Yeah, if you screw up bad stuff happens.
>>
>> Why is that a problem?
>>
>
> Apparently other people never screw up. I used to believe that about
> myself but events proved me wrong. I'm usually sleep-deprived and doing
> half a dozen things at once, so I prefer software not to put things on
> the floor because I *will* trip over those. What I consider "good
> software" makes you intentionally take the safety off when the gun is
> pointed at your foot. Slopware don't much care what happens, and fools
> think that is cute, for a while; then eventually we get tired of limping
> and avoid slopware, it's just part of growing old and stupid.

Quote ..... "What I consider "good software" makes you intentionally

take the safety off when the gun is pointed at your foot."

Why would you want to take the safety off when the gun is pointed at
your foot?? Why would you want to take the safety off when the gun is
pointed at *any* part of your body??

Daniel

[J G Miller]

On Monday, April 8th, 2013, at 01:40:07h +1000, Daniel asked:

> Why would you want to take the safety off when the gun is pointed at
> your foot??

I think the point that was being made by Herr CrankyPuss is that
things like "rm" file deletion should always pop up a dialog
asking if you are really, really sure that you want to delete the file,
rather than just deleting the file, unless one specifically issued the
the rm command with the "safety" off.

Crankypuss just does not "get" the fact that root is the "super user"
who can trash the system in one slip of the finger either at the
command line or in a shell script, eg

rm -fr / tmp/luser/garbage

and in using root powers, a different mindset and extreme caution
is required to the casual luser.

[crankypuss]

No, I'm saying that if I've modified something... a photograph, or a
document, or a script or whatever, that was sitting in my directory, and
I copy it to a directory that is defined as r/o for group, I don't want
the fucking file made r/w for group and readable by world just because I
was busy when I copied it. There's no need for that kind of insecure
bullshit, and umask is a joke.

Apparently many linux people came over from Unix where they'd gotten
used to treating the world with kid gloves in order not to break it.
Not that Windows isn't *much* worse, but Windows is *not* the only
alternative, and there's no reason to leave things broken when they can
be easily fixed.

Now, I'm well ready to move along to other topics and fix this when it
comes to the top of my list, but if the trolls here want to keep
slobbering on the issue, that's fine.

As for you J G Miller, it seems you claimed that SUID as applied to a
directory has some defined semantics, but you have not yet shown
anything other than your claim to indicate what that might be if such
semantics actually exists, which I seriously doubt.

Somehow I am reminded of those sellers of goods who intentionally make
their goods flimsy and easily breakable in order to sell more of them,
and of those software developers who like to snigger at those who have
failed to follow their directions for creeping past the holes they have
left in their slopware.

[Lew Pitcher]

On Sunday 07 April 2013 12:27, in alt.os.linux, crank...@nomail.invalid
wrote:

> On 04/07/2013 09:12 AM, J G Miller wrote:
>> On Monday, April 8th, 2013, at 01:40:07h +1000, Daniel asked:
>>
>>> Why would you want to take the safety off when the gun is pointed at
>>> your foot??
>>
>> I think the point that was being made by Herr CrankyPuss is that
>> things like "rm" file deletion should always pop up a dialog
>> asking if you are really, really sure that you want to delete the file,
>> rather than just deleting the file, unless one specifically issued the
>> the rm command with the "safety" off.
>>
>> Crankypuss just does not "get" the fact that root is the "super user"
>> who can trash the system in one slip of the finger either at the
>> command line or in a shell script, eg
>>
>> rm -fr / tmp/luser/garbage
>>
>> and in using root powers, a different mindset and extreme caution
>> is required to the casual luser.
>>
>
> No, I'm saying that if I've modified something... a photograph, or a
> document, or a script or whatever, that was sitting in my directory, and
> I copy it to a directory that is defined as r/o for group, I don't want
> the fucking file made r/w for group and readable by world just because I
> was busy when I copied it. There's no need for that kind of insecure
> bullshit, and umask is a joke.

May I suggest that, if you are unhappy with how the Linux kernel manages
files and directories, you *change* the objectionable behaviour? You /can/,
you know; the Linux kernel source is readily available, and the licence
permits (even encourages) such changes.

If you need help getting started, may I also suggest that you take a look at
the Kernel Newbies site (http://kernelnewbies.org/).

If such a change is beyond your capabilities, you are encouraged to contact
the kernel maintainers, and present your suggestion directly to them for
evaluation and action.

HTH

[crankypuss]

I know that I can fix it, and don't find it a serious concern. Getting
around to it's another matter. Thank you.

[Lew Pitcher]

On Sunday 07 April 2013 12:27, in alt.os.linux, crank...@nomail.invalid
wrote:

> On 04/07/2013 09:12 AM, J G Miller wrote:
>> On Monday, April 8th, 2013, at 01:40:07h +1000, Daniel asked:
>>
>>> Why would you want to take the safety off when the gun is pointed at
>>> your foot??
>>
>> I think the point that was being made by Herr CrankyPuss is that
>> things like "rm" file deletion should always pop up a dialog
>> asking if you are really, really sure that you want to delete the file,
>> rather than just deleting the file, unless one specifically issued the
>> the rm command with the "safety" off.
>>
>> Crankypuss just does not "get" the fact that root is the "super user"
>> who can trash the system in one slip of the finger either at the
>> command line or in a shell script, eg
>>
>> rm -fr / tmp/luser/garbage
>>
>> and in using root powers, a different mindset and extreme caution
>> is required to the casual luser.
>>
>
> No, I'm saying that if I've modified something... a photograph, or a
> document, or a script or whatever, that was sitting in my directory, and
> I copy it to a directory that is defined as r/o for group, I don't want
> the fucking file made r/w for group and readable by world just because I
> was busy when I copied it. There's no need for that kind of insecure
> bullshit, and umask is a joke.

One question: what if someone hardlinks the file into a directory
that /does/ have group read/write access? What should the behaviour /in
that directory/ be?

Should the act of hardlinking /change/ the file permission bits to match the
target directory's permission bits? And, if so, then how should the
conflict between the permission bits set wrt the original directory vs the
permission bits set wrt the new directory be handled?


Just asking.

[J G Miller]

On Sunday, April 7th, 2013, at 11:02:09h -0600, Crankypuss wrote:

> I know that I can fix it, and don't find it a serious concern.

So now after posting numerous messages claiming that there was
some earth shattering security defect, you now decide to inform
the worlds that you

"don't find it a serious concern."

Did anybody else hear the troll bell sounding?

> Getting around to it's another matter.

The land of vaporware.

[J G Miller]

On Sunday, April 7th, 2013, at 10:27:21h -0600, Cranky Puss wrote:

> it seems you claimed that SUID as applied to a
> directory has some defined semantics,

I was under the mistaken impression that SUID on a directory
behaved the same as SGID.

From <http://content.hccfl.WSU/pollock/aunix1/filepermissions.htm>

QUOTE

Unix File and Directory Permissions and Modes
© 2001–2012 by Wayne Pollock, Tampa Florida USA.

"The SUID bit has no effect on directories."

UNQUOTE

Clearly others are also under the same delusion as I:

from <http://www.dba-oracle.COM/linux/sticky_bit.htm>

QUOTE

Sticky Bit Tips

Linux Tips by Burleson Consulting

"SUID can also be used on a directory to change the ownership
of files created in or moved to that directory to be owned by
the directory owner rather than the user who created it."

UNQUOTE

The confusion arises because as Wonkeypedia explains --

QUOTE

The setuid permission set on a directory is ignored on
UNIX and Linux systems.

FreeBSD can be configured to interpret it *analogously to setgid*,
namely, to force all files and sub-directories to be owned by the
top directory owner.

UNQUOTE

> No, I'm saying that if I've modified something... a photograph, or a
> document, or a script or whatever, that was sitting in my directory, and
> I copy it to a directory that is defined as r/o for group, I don't want

> the <expletive deleted> file made r/w for group and readable by world

> just because I was busy when I copied it.

When you copy the file using the same name it will have the same
permsissions as the original.

umask applies to newly created files.

If the file is readable in the directory by others, they will be
able to copy it and then edit their own version and deface it contrary
to your wishes and publish it on the web.

If the directory is 0750, regardless of whether or not the file
is world readable, the world will not be able to access the file.

If you are too lazy to check the ownership and permissions on
the files that you copy over, you only have yourself to blame,
and not be using alt.os.linux for matters arising from your own
administrative shortcomings.

[Lew Pitcher]

A correction - I didn't read chmod(1) correctly, so...

On Tuesday 02 April 2013 18:18, in alt.os.linux, lpit...@teksavvy.com
wrote:

> On Tuesday 02 April 2013 16:51, in alt.os.linux, crank...@nomail.invalid
> wrote:
>
>> There is a directory that I want to be read/write for me, read/only for
>> group, and inaccessible for others.
>>
>> I tried setting it up as "D -G- rwx r-x ---" with owner=1000 and
>> group=1003. That worked fine with one exception. Anything that I
>> copied to or saved to the directory turned out to be "F --- rw- rw- r--".
> [snip]

>> For a directory you want to be r/w for yourself, r/o to group, and
>> inaccessible to others, what's the correct way to set it up?
>

> Do this
>
> 1) Correct the ownership of the directory, and all it's files, so that all
> are owned by user 1000, group 1003
> chown -R 1000:1003 /path/to/directory
>
> 2) Correct the access rights to the directory, so that the owning user can
> read directory, write/modify and search directory entries, the owning
> group can read and search directory entries, and all others have no
> access to the directory.
> chmod u=rwx,g=rX,o= /path/to/directory

Should be
chmod u=rwx,g=rs,o= /path/to/directory

> 3) Correct the access rights to each file, so that the owning user can
> read
> and write the file data, the owning group can only read the file data,
> and all others have no access to the file data.
> chmod u=rw,g=r,o= /path/to/directory/*
> or
> find /path/to/directory -type f -exec chmod u=rw,g=r,o= {} +
>
> 4) To ensure that new files get the proper permissions, set your umask to
> 037 /before/ creating files or manipulating additional files in the
> directory.

[crankypuss]

On 04/07/2013 01:29 PM, J G Miller wrote:
> On Sunday, April 7th, 2013, at 11:02:09h -0600, Crankypuss wrote:
>
>> I know that I can fix it, and don't find it a serious concern.
>
> So now after posting numerous messages claiming that there was
> some earth shattering security defect, you now decide to inform
> the worlds that you
>
> "don't find it a serious concern."

I'm not seriously concerned about being able to fix it; I've done
operating system guts before.

> Did anybody else hear the troll bell sounding?
>
>> Getting around to it's another matter.
>
> The land of vaporware.
>

Yeah, life is tough, innit? I'm just sitting here using the code I've
written to make life more convenient, not distributing a stick of it, yet.

[crankypuss]

Hardlinks are just alternate names, right? So the file will have the
permissions of the group where the file actually resides, right? I
don't see that as an issue; maybe it is, that's why we test things, not
only to verify that they work, but to verify that they do what we want
them to do.

> Should the act of hardlinking /change/ the file permission bits to match the
> target directory's permission bits? And, if so, then how should the
> conflict between the permission bits set wrt the original directory vs the
> permission bits set wrt the new directory be handled?

I don't see why a hardlink should change the file, it doesn't do that
now does it?

It isn't as though I've suggested something wild and crazy, as far as I
know. Just the setting of a bit to further constrain the permissions of
what resides in that directory, one more logical AND after umask is
applied. If you make a hardlink such that the link resides in the
constrained directory, and the permissions are beyond what is allowed
for the directory, the attempt to hardlink should probably fail with an
"invalid permissions" indication.

> Just asking.
>

I'll let you know once I've gotten around to implementing it. I
certainly wouldn't add some feature that would screw around with what
has proven to be useful. I'm not saying it should be default behaviour,
that every directory should be constrained. But from a data management
point of view, it seems to me that if you set the directory permissions
to "rwx r-x ---" there should be a reasonable way of ensuring that no
file within that directory exceeds those permissions.

[crankypuss]

At least you had the guts to admit that you were wrong, good on you for
that.

>> No, I'm saying that if I've modified something... a photograph, or a
>> document, or a script or whatever, that was sitting in my directory, and
>> I copy it to a directory that is defined as r/o for group, I don't want
>> the <expletive deleted> file made r/w for group and readable by world
>> just because I was busy when I copied it.
>
> When you copy the file using the same name it will have the same
> permsissions as the original.
>
> umask applies to newly created files.
>
> If the file is readable in the directory by others, they will be
> able to copy it and then edit their own version and deface it contrary
> to your wishes and publish it on the web.
>
> If the directory is 0750, regardless of whether or not the file
> is world readable, the world will not be able to access the file.
>
> If you are too lazy to check the ownership and permissions on
> the files that you copy over, you only have yourself to blame,

Typical long-time administrator response, everything is either "working
as designed" or "user error". Ever hear the phrase "broken as
designed"? Think about it. Real flexibility allows not only freedom,
but constraint.

> and not be using alt.os.linux for matters arising from your own
> administrative shortcomings.
>

Look at the original post again, read it this time. I asked for help in
understanding how it works. After coming to understand how it works, I
don't like the way it works, and unless I change my mind before I get
around to it, I'll change the way it works on the systems that I use.

I appreciate the help of everybody who has posted to this thread. I'm
not trying to whine anybody into doing anything. But I could never have
grasped the concept that it could really be such an operational mess all
by myself.

The response of most linux administrator types is understandable enough,
if things were set up properly many of them would be out of a job.

[Lew Pitcher]

On Sunday 07 April 2013 17:53, in alt.os.linux, crank...@nomail.invalid

Sort of. Hardlinks are alternate paths to the same file. The permissions and
ownership reside with the file, not the name or the path.

> So the file will have the
> permissions of the group where the file actually resides, right?

In those terms, the file "actually resides" in two different directories.
Each with it's own permission structure. In reality, the file doesn't
reside in /either/ directory; only a pointer to the file exists in each
directory, not the file or it's metadata.

So, no, the file will *not* have the permissions of the group where the
file "actually resides".

> I
> don't see that as an issue; maybe it is, that's why we test things, not
> only to verify that they work, but to verify that they do what we want
> them to do.
>
>> Should the act of hardlinking /change/ the file permission bits to match
>> the target directory's permission bits? And, if so, then how should the
>> conflict between the permission bits set wrt the original directory vs
>> the permission bits set wrt the new directory be handled?
>
> I don't see why a hardlink should change the file, it doesn't do that
> now does it?

No, but you are suggesting (by implication) that it should.

Consider, you create a directory that enforces specific permission settings
on it's files, including group ownership. You then hardlink the
file /etc/passwd into your directory.

Now, what permissions and ownership should /etc/passwd have? Remember, the
names may reside in different directories, but the /file/ hasn't changed.

> It isn't as though I've suggested something wild and crazy, as far as I
> know. Just the setting of a bit to further constrain the permissions of
> what resides in that directory, one more logical AND after umask is
> applied. If you make a hardlink such that the link resides in the
> constrained directory, and the permissions are beyond what is allowed
> for the directory, the attempt to hardlink should probably fail with an
> "invalid permissions" indication.
>
>> Just asking.
>>
>
> I'll let you know once I've gotten around to implementing it. I
> certainly wouldn't add some feature that would screw around with what
> has proven to be useful. I'm not saying it should be default behaviour,
> that every directory should be constrained. But from a data management
> point of view, it seems to me that if you set the directory permissions
> to "rwx r-x ---" there should be a reasonable way of ensuring that no
> file within that directory exceeds those permissions.

[crankypuss]

Understood.

>> So the file will have the
>> permissions of the group where the file actually resides, right?

What I typed there isn't what I meant; I'm not sure why the word "group"
got into that sentence at all, definitely some kind of brain-fart. I
meant that the file itself, the inode that points to the file data,
defines its ownership and permissions. If its creation was constrained
by the directory where it was originally created, then it would either
have the permissions allowed within that directory, or its attempted
creation would have failed.

> In those terms, the file "actually resides" in two different directories.

I'd quibble with that, pointing out that the inode "owning" the file
itself, is only in... well I suppose "in" only relates to whatever
hardlinks point to it. That inode is only at one place, no matter how
many links point to it.

> Each with it's own permission structure. In reality, the file doesn't
> reside in /either/ directory; only a pointer to the file exists in each
> directory, not the file or it's metadata.
>
> So, no, the file will *not* have the permissions of the group where the
> file "actually resides".

I think we have the same understanding on that.

>> I
>> don't see that as an issue; maybe it is, that's why we test things, not
>> only to verify that they work, but to verify that they do what we want
>> them to do.
>>
>>> Should the act of hardlinking /change/ the file permission bits to match
>>> the target directory's permission bits? And, if so, then how should the
>>> conflict between the permission bits set wrt the original directory vs
>>> the permission bits set wrt the new directory be handled?
>>
>> I don't see why a hardlink should change the file, it doesn't do that
>> now does it?
>
> No, but you are suggesting (by implication) that it should.

The implication exists but I'm not sure it's me who's implying it.

> Consider, you create a directory that enforces specific permission settings
> on it's files, including group ownership. You then hardlink the
> file /etc/passwd into your directory.

What makes you think you should be able to hardlink /etc/passwd into any
given directory? Because that's the way it's always been done on linux,
because it was the way it was always done on Unix? Why is it that
symlinks have no permissions explicitly associated with them [1],
because that's how it's always been done on linux because it's how it
always worked on Unix? Frankly I'm not at all impressed with the way
either type of link works, each has its uses but each also has
drawbacks; it feels like there ought to be a better solution.

> Now, what permissions and ownership should /etc/passwd have? Remember, the
> names may reside in different directories, but the /file/ hasn't changed.

I don't have an answer for that just now.

I'm not even sure that what I end up will be recognizable as "linux".
There are a lot of things people believe about "linux". A lot of people
see it as a system where many users are logged on simultaneously via ssh
or whatever. And that's a valid traditional view, as far as I can tell.

On the other hand, I'm looking at something a bit different. A system
that has a thin-client interface to what people usually think of as
"linux", assuming that's what the thin-client part is connected to...
think of it as a divided linux where one part is pure server and the
other part is thin-client, the thin-client part is turing-complete in
terms of backup, restore, and installation; the pure server part might
be set up as a pure server, or not even configured in at all.

It isn't as though linux as it is today is the best we can ever have;
it's great, it's solid, but it isn't perfect. Lots of the things that
hold it back came over from Unix after the boyz ginned it up in their
spare time. Unix started out ad-hoc, and linux inherited most of that,
and then added its own ad-hoc-ness on top of it. And of course most
everybody has a personal profit motive in it, RedHat, Canonical,
whoever, they're all looking to get rich and retire off linux, and you
don't do that by making lots of basic changes. Well I'm already retired
and all I'm looking to do is put together something maybe a little
different, something to serve as a base for the other stuff that I'd
like to build.

I'm not going to make any friends by listing all the things I see as
"wrong" with linux, and the administrator crowd that believes the
core-commands and their funky option-set were chiseled onto stone
tablets by gods aren't going to convince me that linux is perfect. I've
been around too long to become a linux religious convert, but it seems
like a good solid base to make something out of.

[J G Miller]

On Sunday, April 7th, 2013, at 16:07:07h -0600, Cranky Puss wrote:

> At least you had the guts to admit that you were wrong

If one does not learn from one's mistakes then one is going
to continue making them.

> I asked for help in understanding how it works.
> After coming to understand how it works,

But you are not giving the impression that you do
fully understand how it works.

> I don't like the way it works,

That is your prerogative.

> and unless I change my mind before I get around to it,
> I'll change the way it works on the systems that I use.

Again that is your prerogative.

> But I could never have grasped the concept that it could really
> be such an operational mess all by myself.

Well, overall GNU/Linux systems are a bit of a mess -- as
HAL did say -- "There is no question about it."

If you think things are in a mess now, just wait until the
X11 / Wayland / Mir splinter becomes reality.

> The response of most linux administrator types is understandable enough,
> if things were set up properly many of them would be out of a job.

A comptuer system is a tool to getting a job done. The administrator's job
is to make sure the tool is best adjusted to get the job done and to
always be available to get the job done. Computer systems are not static
consumer devices only doing a limited set of pre-determined tasks, which
you do of course know and realize.

[Jasen Betts]

On 2013-04-07, crankypuss <crank...@nomail.invalid> wrote:
> this is, or you may accept that I have found it to be a pain in the ass,
> and STFU about it.

RTFM and GTFOI

[crankypuss]

On 04/07/2013 05:16 PM, J G Miller wrote:
> On Sunday, April 7th, 2013, at 16:07:07h -0600, Cranky Puss wrote:
>
>> At least you had the guts to admit that you were wrong
>
> If one does not learn from one's mistakes then one is going
> to continue making them.

Yes, at best... some mistakes are fatal.

>> I asked for help in understanding how it works.
>> After coming to understand how it works,
>
> But you are not giving the impression that you do
> fully understand how it works.

I'm not much interested in, or responsible for, the conclusions others
draw, and when convinced that I "fully understand" how something
works... well, "fully" is a very large word for its size.

>> I don't like the way it works,
>
> That is your prerogative.
>
>> and unless I change my mind before I get around to it,
>> I'll change the way it works on the systems that I use.
>
> Again that is your prerogative.
>
>> But I could never have grasped the concept that it could really
>> be such an operational mess all by myself.
>
> Well, overall GNU/Linux systems are a bit of a mess -- as
> HAL did say -- "There is no question about it."

Software messiness is a matter of degree, not something one can escape
from entirely; it's the apparently-inescapable disconnect between what
we mean and what we say, combined with the building inertia as things
develop. Hardly anybody is willing to throw it all away and start over,
except for very trivial software; so we fix it, and it gets ever
messier, until finally one day we find ourselves forced to do something
different.

> If you think things are in a mess now, just wait until the
> X11 / Wayland / Mir splinter becomes reality.

Yesterday I downloaded a bunch of updates from the Ubuntu repository,
and that may very well be the last set that I install; this morning I
started setting up a spare drive for building something a little
different, a LFS to begin with. Like everyone else I'm unwilling to
begin with an Assembler manual and write it from ground zero, so it's a
matter of progressive shifting from what-is to what-will-be. I'm hoping
the linux kernel will not be too unwieldy to use as a base, it may be
somewhat messy but it seems very solid.

>> The response of most linux administrator types is understandable enough,
>> if things were set up properly many of them would be out of a job.
>
> A comptuer system is a tool to getting a job done. The administrator's job
> is to make sure the tool is best adjusted to get the job done and to
> always be available to get the job done.

That's sort of what I was pointing out, the linux administrator's job is
to manually deal with the messiness that hasn't yet been cleaned up; if
things were sufficiently cleaned up, well there they'd be, fishing all
day, or looking for another job.

> Computer systems are not static
> consumer devices only doing a limited set of pre-determined tasks, which
> you do of course know and realize.

Unfortunately they are also not yet static devices for doing an
unlimited set of tasks... the ultimate general purpose operating system
on a chip is not yet here. It is a whole lot closer now though than it
was 40 years ago, and given the rate at which things are progressing we
might live to see something very good and very general purpose on a chip.