[Cooker] [2009.1] What is errcode: 13 when trying to allocate files as root

[Oden Eriksson]

söndagen den 5 juli 2009 04.38.10 skrev  Steve Morris:

[...]

Why do you complicate this?

rpm -e mysql
rm -rf /var/lib/mysq/mysql
urpmi mysql
/etc/rc.d/init.d/mysqld start

This produces a perfectly working mysql for most or maybe even 99.9999% of the
users.

--
Regards // Oden Eriksson

[Pascal Terjan]

On Sat, Jul 4, 2009 at 9:01 AM, Andrey Borzenkov<arvidjaar@...> wrote:

> On Thursday 02 of July 2009 11:52:29 Guillaume Rousse wrote:
>> Thomas Backlund a écrit :
>> > what's the output of: rpm -qa |grep mysql
>>
>> just for the record: it's way quicker to use 'rpm -qa *mysql*'
>
> Actually my experience is exactly opposite. Which is logical - rpm -qa
> does not need to do *any* database processing at all, just dump contents
> of index.
>
> And grep matching is apparently faster that rpm ones.
>

[pterjan@plop gobject-introspection]$ time rpm -qa 'rpm*' > /dev/null
2.38user 0.89system 0:27.45elapsed 11%CPU (0avgtext+0avgdata 0maxresident)k
100776inputs+8outputs (4major+9492minor)pagefaults 0swaps
[pterjan@plop gobject-introspection]$ time rpm -qa 'rpm*' > /dev/null
1.19user 0.24system 0:01.78elapsed 80%CPU (0avgtext+0avgdata 0maxresident)k
800inputs+0outputs (10major+9482minor)pagefaults 0swaps
[pterjan@plop gobject-introspection]$ time rpm -qa | grep '^rpm' > /dev/null
1.31user 0.25system 0:01.85elapsed 84%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+8outputs (0major+9244minor)pagefaults 0swaps
[pterjan@plop gobject-introspection]$ time rpm -qa | grep '^rpm' > /dev/null
1.31user 0.24system 0:01.88elapsed 82%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+9240minor)pagefaults 0swaps
[pterjan@plop gobject-introspection]$ time rpm -qa 'rpm*' > /dev/null
1.18user 0.24system 0:01.65elapsed 85%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+9500minor)pagefaults 0swaps

The first one is not significant but then rpm seems to be slightly faster
In the past it was much faster as rpm -qa used to check signature of
each header before displaying so reducing the number of matches
reduced the computation a lot

[Colin Guthrie-8]

'Twas brillig, and Steve Morris at 05/07/09 03:38 did gyre and gimble:

> On 02/07/09 09:26, Colin Guthrie wrote:
>> 'Twas brillig, and Steve Morris at 01/07/09 22:06 did gyre and gimble:
>>> On 01/07/09 08:40, Colin Guthrie wrote:
>>>> 'Twas brillig, and Frank Griffin at 30/06/09 21:49 did gyre and gimble:
>>>>> Steve Morris wrote:
>>>>>> /usr/sbin/mysqld: Can't create/write to file '/root/tmp/ibSy10pn'
>>>>>> (Errcode: 13)
>>>>>>
>>>>>> What does this mean and why does it occur even if I issue chmod 777
>>>>>> /root/tmp
>>>>>>
>>>>>
>>>>> Start with /usr/include/errno.h and follow the #includes until you
>>>>> find
>>>>> the standard errno numbers.
>>>>>
>>>>> Then realize that you can't create in /root/tmp if you can't cd to
>>>>> /root, which has perms rwx------.  ;)
>>>>
>>>> Have a look in the /etc/sysconfig/mysql file and in particular
>>>> .rpmnew variants.
>>>>
>>>> Of particular interest are the lines:
>>>>
>>>> # (oe) set TMPDIR and TMP environment variables
>>>> TMPDIR="/var/tmp"
>>>> TMP="${TMPDIR}"
>>>>
>>>> These variables ensure things work form the init scripts etc. but
>>>> wont cover running them manually. If you set these vars yourself and
>>>> export them, things will work as expected.
>>>>
>>>> Col
>>>>
>>> What init scripts are you talking about? At the current time running
>>> mysqld from a shell under root is the only way to start it as
>>> /etc/rc.d/init.d/mysqld does not work when started from  a shell
>>> under root (mysql is not listed as a service in mcc and as far as I
>>> can tell there is no script in /etc/rc.d/rc5.d), and the recommended
>>> script to run of mysql_safe as far as I can tell is not provided by
>>> the Mandriva rpms, and as at the stage of getting this error I had
>>> not explicitly specified the temporary file path in /etc/my.cnf in
>>> the mysqld section, it should be using the Mandriva defaults which
>>> based on what you have said it isn't, hence why not? I have also
>>> created /home/mysql even though this is not required.
>>
>> I suspect you're running into a similar problem I had with an upgrade
>> of mysql. Actually, now I think about it, I was trying to reinit the
>> mysql directory after a disk failure.
>>
>> Turns out you cannot run mysql_install_db as root as this then creates
>> the files owned by root rather than the mysql user.
>>
>> And if you try and run it under su -u mysql then it cannot find it's
>> temp dir.
>>
>> I think you just need to (as root):
>>
>> 1. service mysqld stop
>> 2. rm -rf /var/lib/mysql
>> 3. mkdir /var/lib/mysql
>> 4. chown mysql.mysql /var/lib/mysql
>> 5. su -c "mysql_install_db" mysql
>> 6. service mysqld start
>>
> I get the same error above from the install_db and upgrade scripts also
> even though I follow the mysql documentation.
> To work around the issues I have had to do the following even though
> /var/lib/mysql and all contents were owned by mysql.mysql:
>
> su -
> pkill mysqld
> rm -Rf /var/lib/mysq/mysql
> chown -R mysql:mysql /var/lib/mysql
> cd /var/lib/mysql
> mysql_install_db --user=mysql
>
> This successfully created the databases in /var/lib/mysql/mysql owned by
> mysql.

What is the output ofr the mysql_install_db script here. I had to read
it quite carefully to realise that it couldn't write to the temp space
and even tho' the mysql database was created, it certainly was not
initialised correctly. The TMP and TMPDIR stuff I mentioned in my
previous email (before step 1, which I guess I could have made clearer)
made this work for me. Please double check.

Col

--

Colin Guthrie
cguthrie(at)mandriva.org
http://colin.guthr.ie/

Day Job:
   Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
   Mandriva Linux Contributor [http://www.mandriva.com/]
   PulseAudio Hacker [http://www.pulseaudio.org/]
   Trac Hacker [http://trac.edgewall.org/]

[Steve Morris-5]

On 05/07/09 23:07, Colin Guthrie wrote:

> 'Twas brillig, and Steve Morris at 05/07/09 03:38 did gyre and gimble:
>> On 02/07/09 09:26, Colin Guthrie wrote:
>>> 'Twas brillig, and Steve Morris at 01/07/09 22:06 did gyre and gimble:
>>>> On 01/07/09 08:40, Colin Guthrie wrote:
>>>>> 'Twas brillig, and Frank Griffin at 30/06/09 21:49 did gyre and
>>>>> gimble:
>>>>>> Steve Morris wrote:
>>>>>>> /usr/sbin/mysqld: Can't create/write to file '/root/tmp/ibSy10pn'
>>>>>>> (Errcode: 13)
>>>>>>>
>>>>>>> What does this mean and why does it occur even if I issue chmod 777
>>>>>>> /root/tmp
>>>>>>>
>>>>>>
>>>>>> Start with /usr/include/errno.h and follow the #includes until
>>>>>> you find
>>>>>> the standard errno numbers.
>>>>>>
>>>>>> Then realize that you can't create in /root/tmp if you can't cd to
>>>>>> /root, which has perms rwx------.  ;)
>>>>>
>>>>> Have a look in the /etc/sysconfig/mysql file and in particular
>>>>> .rpmnew variants.
>>>>>
>>>>> Of particular interest are the lines:
>>>>>
>>>>> # (oe) set TMPDIR and TMP environment variables
>>>>> TMPDIR="/var/tmp"
>>>>> TMP="${TMPDIR}"
>>>>>
>>>>> These variables ensure things work form the init scripts etc. but
>>>>> wont cover running them manually. If you set these vars yourself
>>>>> and export them, things will work as expected.
>>>>>
>>>>> Col
>>>>>
>>>> What init scripts are you talking about? At the current time
>>>> running mysqld from a shell under root is the only way to start it
>>>> as /etc/rc.d/init.d/mysqld does not work when started from  a shell
>>>> under root (mysql is not listed as a service in mcc and as far as I
>>>> can tell there is no script in /etc/rc.d/rc5.d), and the
>>>> recommended script to run of mysql_safe as far as I can tell is not
>>>> provided by the Mandriva rpms, and as at the stage of getting this
>>>> error I had not explicitly specified the temporary file path in
>>>> /etc/my.cnf in the mysqld section, it should be using the Mandriva
>>>> defaults which based on what you have said it isn't, hence why not?
>>>> I have also created /home/mysql even though this is not required.
>>>
>>> I suspect you're running into a similar problem I had with an
>>> upgrade of mysql. Actually, now I think about it, I was trying to
>>> reinit the mysql directory after a disk failure.
>>>
>>> Turns out you cannot run mysql_install_db as root as this then
>>> creates the files owned by root rather than the mysql user.
>>>
>>> And if you try and run it under su -u mysql then it cannot find it's
>>> temp dir.
>>>
>>> I think you just need to (as root):
>>>
>>> 1. service mysqld stop
>>> 2. rm -rf /var/lib/mysql
>>> 3. mkdir /var/lib/mysql
>>> 4. chown mysql.mysql /var/lib/mysql
>>> 5. su -c "mysql_install_db" mysql
>>> 6. service mysqld start
>>>
>> I get the same error above from the install_db and upgrade scripts
>> also even though I follow the mysql documentation.
>> To work around the issues I have had to do the following even though
>> /var/lib/mysql and all contents were owned by mysql.mysql:
>>
>> su -
>> pkill mysqld
>> rm -Rf /var/lib/mysq/mysql
>> chown -R mysql:mysql /var/lib/mysql
>> cd /var/lib/mysql
>> mysql_install_db --user=mysql
>>
>> This successfully created the databases in /var/lib/mysql/mysql owned
>> by mysql.
>
> What is the output ofr the mysql_install_db script here. I had to read
> it quite carefully to realise that it couldn't write to the temp space
> and even tho' the mysql database was created, it certainly was not
> initialised correctly. The TMP and TMPDIR stuff I mentioned in my
> previous email (before step 1, which I guess I could have made
> clearer) made this work for me. Please double check.
>
> Col
>

I checked the /etc/sysconfig/mysql file on my system and it is the same

as what you listed. I also checked the bash environment and by default
it uses $HOME/tmp for the tmp and tmpdir environment variables which is
why su -u mysql can't process temp files, because /home/mysql doesn't
exist unless you have explicitly created it. That's where the --user
parameter comes in, which runs the processes under user mysql in
whatever environment you have su'ed to.
It appears that in the Mandriva implementation, before one follows the
upstream documentation to install/upgrade mysql, one has to either
explicitly tell mysql what temp path to use in /etc/my.cnf or manually
run /etc/sysconfig/mysql to override the bash environment.
Why I say in the Mandriva implementation is because the upstream
documentation documents 2 methods for starting the server,
/usr/bin/mysqld --user=mysql or /usr/bin/mysqld_safe --user=mysql, in
Mandriva's implementation mysqld in in /usr/sbin and mysqld_safe doesn't
exist.
While we are on the topic of Mandriva's implementation, is there any
plans on providing the stable 5.3 implementation as a replacement for
5.1.34?

regards,
Steve


[samorris.vcf]

---

begin:vcard
fn:Steve Morris
n:Morris;Steve
email;internet:samorris@...
x-mozilla-html:TRUE
version:2.1
end:vcard

---

[Colin Guthrie-8]

'Twas brillig, and Steve Morris at 05/07/09 22:20 did gyre and gimble:
> I checked the /etc/sysconfig/mysql file on my system and it is the same
> as what you listed. I also checked the bash environment and by default
> it uses $HOME/tmp for the tmp and tmpdir environment variables which is
> why su -u mysql can't process temp files, because /home/mysql doesn't
> exist unless you have explicitly created it. That's where the --user
> parameter comes in, which runs the processes under user mysql in
> whatever environment you have su'ed to.

Yes I know, that's why I told you to set them before running the
commands. You've still not answered my question about whether this
sequence of commands worked. I'm asking you to try it so we can gather
information about what adjustments are needed.

> It appears that in the Mandriva implementation, before one follows the
> upstream documentation to install/upgrade mysql, one has to either
> explicitly tell mysql what temp path to use in /etc/my.cnf or manually
> run /etc/sysconfig/mysql to override the bash environment.
> Why I say in the Mandriva implementation is because the upstream
> documentation documents 2 methods for starting the server,
> /usr/bin/mysqld --user=mysql or /usr/bin/mysqld_safe --user=mysql, in
> Mandriva's implementation mysqld in in /usr/sbin and mysqld_safe doesn't
> exist.

mysqld_safe has been deprecated a long time ago. It's been superseded by
mysqlmanager upstream a long time ago.

The "mandriva implementation" you are referring too is not really
anything to do with the mysql package itself - it's more to do with the
system environment. It may be that we need to create a dummy home
directory with the appropriate .bashrc to set the tmp dir env vars set
correctly, but without feedback this is not going to happen.

Col




--

Colin Guthrie
cguthrie(at)mandriva.org
http://colin.guthr.ie/

Day Job:
   Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
   Mandriva Linux Contributor [http://www.mandriva.com/]
   PulseAudio Hacker [http://www.pulseaudio.org/]
   Trac Hacker [http://trac.edgewall.org/]

[Steve Morris-5]

On 06/07/09 07:27, Colin Guthrie wrote:

> 'Twas brillig, and Steve Morris at 05/07/09 22:20 did gyre and gimble:
>> I checked the /etc/sysconfig/mysql file on my system and it is the
>> same as what you listed. I also checked the bash environment and by
>> default it uses $HOME/tmp for the tmp and tmpdir environment
>> variables which is why su -u mysql can't process temp files, because
>> /home/mysql doesn't exist unless you have explicitly created it.
>> That's where the --user parameter comes in, which runs the processes
>> under user mysql in whatever environment you have su'ed to.
>
> Yes I know, that's why I told you to set them before running the
> commands. You've still not answered my question about whether this
> sequence of commands worked. I'm asking you to try it so we can gather
> information about what adjustments are needed.

I've only defined a user to the mysql databases which I can create again

easily, and all the performance tuning parameters I have implemented are
in /etc/my.cnf so these wont be lost. I can delete the database
directory and rename the my.cnf file and test out the scripts to see
what is needed.

>
>> It appears that in the Mandriva implementation, before one follows
>> the upstream documentation to install/upgrade mysql, one has to
>> either explicitly tell mysql what temp path to use in /etc/my.cnf or
>> manually run /etc/sysconfig/mysql to override the bash environment.
>> Why I say in the Mandriva implementation is because the upstream
>> documentation documents 2 methods for starting the server,
>> /usr/bin/mysqld --user=mysql or /usr/bin/mysqld_safe --user=mysql, in
>> Mandriva's implementation mysqld in in /usr/sbin and mysqld_safe
>> doesn't exist.
>
> mysqld_safe has been deprecated a long time ago. It's been superseded
> by mysqlmanager upstream a long time ago.

Its interesting you say this, I have tried mysqlmanager once and

considered it to not provide any useful functionality and haven't used
it again, but the upstream documentation I have is recommending
mysqld_safe as the preferred method of starting the server and writes
the documentation on the assumption that is how the server is started (I
think this documentation is for V5.3 of mysql but I am not sure at the
moment). Also /etc/my.cnf appears to have a configuration section for
mysqld and one for mysqld_safe, which may be a carry over from the
version of mysql used in 2009.0, but either way mysql-administrator
prompts for which one it is to manipulate when configuring parameters.
>
> The "mandriva implementation" you are referring too is not really
> anything to do with the mysql package itself - it's more to do with
> the system environment. It may be that we need to create a dummy home
> directory with the appropriate .bashrc to set the tmp dir env vars set
> correctly, but without feedback this is not going to happen.
This is true, but /etc/sysconfig/mysql, as far as I can tell, is not
supplied with upstream mysql hence is part of Mandriva's mysql
implementation. Which also raises the question of why is this script set
the temp environment to /var/tmp? The myriad tmp directories that seem
to be used by various environment are a real pain in the butt for people
like me who have explicitly said they want /tmp cleaned up every boot,
because that means the temp file cleanup we have asked for is
potentially not happening.

regards,
Steve

>
> Col
>
>
>
>

[samorris.vcf]

---

begin:vcard
fn:Steve Morris
n:Morris;Steve
email;internet:samorris@...
x-mozilla-html:TRUE
version:2.1
end:vcard

---

[Colin Guthrie-8]

'Twas brillig, and Steve Morris at 06/07/09 22:18 did gyre and gimble:
> This is true, but /etc/sysconfig/mysql, as far as I can tell, is not
> supplied with upstream mysql hence is part of Mandriva's mysql
> implementation. Which also raises the question of why is this script set
> the temp environment to /var/tmp?

/var/tmp is an accepted standard location for a temp folder as used by
system services.

The reason we have to set this is that other security features in
mandriva specifically *do not* use a global temporary folder for users
to prevent folder poising and effectively DoSing other users by creating
files known to be used by other users (e.g. the old /tmp/.esd-605 socket
or similar such things - if another user - i.e. not UID 605 - created
that file before UID 605 could they would be DoSing that user's account).

So all users have their TMP and TMPDIR env vars set to (usually)
$HOME/tmp. This means that they have a "private" temporary folder and
DoSing does not happen.

DoSing is not the only problem there are numerious other security
problems that could result from using shared tmp. I believe that the
private temp is a feature of msec and is only set when the security
level is suitably set, but I'm not 100% sure here.

MySQL (as it runs as the MySQL user) will also have it's TMP and TMPDIR
variables set to $HOME/tmp, but as mysql's home dir is dummy, these temp
folders do not exist. MySQL needs a valid temp location to operate
successfully and to run mysql_install_db etc.

This is why it is imperative that you set these values before running
any MySQL command manually. And this is why the sysconfig file exists.


FWIW, sysconfig files are a standard approach to providing configuration
directives for system integration that is commonly used on RedHat,
Mandriva and several other distros.

Col

--

Colin Guthrie
cguthrie(at)mandriva.org
http://colin.guthr.ie/

Day Job:
   Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
   Mandriva Linux Contributor [http://www.mandriva.com/]
   PulseAudio Hacker [http://www.pulseaudio.org/]
   Trac Hacker [http://trac.edgewall.org/]

[Eugeni Dodonov]

Colin Guthrie wrote:
> DoSing is not the only problem there are numerious other security
> problems that could result from using shared tmp. I believe that the
> private temp is a feature of msec and is only set when the security
> level is suitably set, but I'm not 100% sure here.

It was like this when security_level > 2 with old msec. With new msec
(2010+) it is handled by SECURE_TMP variable, so you can enable/disable
it on any security level.

--
Eugeni Dodonov

[Steve Morris-5]

On 07/07/09 18:13, Colin Guthrie wrote:

> 'Twas brillig, and Steve Morris at 06/07/09 22:18 did gyre and gimble:
>> This is true, but /etc/sysconfig/mysql, as far as I can tell, is not
>> supplied with upstream mysql hence is part of Mandriva's mysql
>> implementation. Which also raises the question of why is this script
>> set the temp environment to /var/tmp?
>
> /var/tmp is an accepted standard location for a temp folder as used by
> system services.
>
> The reason we have to set this is that other security features in
> mandriva specifically *do not* use a global temporary folder for users
> to prevent folder poising and effectively DoSing other users by
> creating files known to be used by other users (e.g. the old
> /tmp/.esd-605 socket or similar such things - if another user - i.e.
> not UID 605 - created that file before UID 605 could they would be
> DoSing that user's account).
>
> So all users have their TMP and TMPDIR env vars set to (usually)
> $HOME/tmp. This means that they have a "private" temporary folder and
> DoSing does not happen.

That's fine, so what should happen then, is when a user has explicitly

specified that they want the temp environment cleaned at boot then all
directories that are used for temporary file storage should be cleaned
out at boot time, which I haven't seen any evidence of happening. There
is also the argument I have seen that the temp environment should never
be anything other than tmpfs, which hence means that every temp
directory in use by the distribution should be using tmpfs, but the
disadvantage of tmpfs is that the arbitrary size limit imposed by tmpfs
makes a mockery of that environment, as it makes /tmp totally useless
for applications like k3b who by default use /tmp as their temp
directory where by default it stores its iso files it builds and the
arbitrary tmpfs imposed size limit is too small even for a cd.

>
> DoSing is not the only problem there are numerious other security
> problems that could result from using shared tmp. I believe that the
> private temp is a feature of msec and is only set when the security
> level is suitably set, but I'm not 100% sure here.
>
> MySQL (as it runs as the MySQL user) will also have it's TMP and
> TMPDIR variables set to $HOME/tmp, but as mysql's home dir is dummy,
> these temp folders do not exist. MySQL needs a valid temp location to
> operate successfully and to run mysql_install_db etc.

Yes, this is true but if /etc/my.cnf is not supplied with a valid temp

specification then it is going to use whatever the system defaults are,
of which these are the private tmp directory, which is never going to
work if the instructions for performing these functions are followed. So
in reality rather that supplying a /etc/sysconfig/mysqld script and
expecting people to know that they need to run that, what should be
happening is the distribution should be supplying /etc/my.cnf with the
appropriate parameters for the temp locations specified, thereby not
invalidating upstream instructions on how the process should be run.
>
>
> This is why it is imperative that you set these values before running
> any MySQL command manually. And this is why the sysconfig file exists.
The /etc/sysconfig.mysqld script doesn't work. As yet I don't know why,
but it does not overwrite the tmp and tmpdir environment variables.
However, if I manually issue the commands it is using to set these
variables they work, so I'm not quite sure why they don't from the
script. I also think from memory the script was not executable by default.
>
>
> FWIW, sysconfig files are a standard approach to providing
> configuration directives for system integration that is commonly used
> on RedHat, Mandriva and several other distros.
Thats all very well, but upstream applications that are distribution
independent, like mysql, don't supply these files, which presumably
means it is not a universal Linux standard. Ignoring this, what you seem
to be indicating is that any upstream software that does not implement
their configuration processes via this method should not be used in
Mandriva, which is a very dangerous approach for the survival of the
distribution. If users cannot run the software they want in the
distribution they are going to go elsewhere, which I would have thought
is a situation the organisation wouldn't want.

Sorry for the late response but wireless regulatory domain usage in the
distribution is starting to randomly stuff me around by the distro
randomly failing to find it and disabling DNS resolution because of it,
and, as I reported in another thread if I leave the system running for
1/2 hr the issue seems to fix itself.

regards,
Steve

>
> Col
>

[samorris.vcf]

---

begin:vcard
fn:Steve Morris
n:Morris;Steve
email;internet:samorris@...
x-mozilla-html:TRUE
version:2.1
end:vcard

---

[Frank Griffin-4]

Steve Morris wrote:
> The /etc/sysconfig.mysqld script doesn't work. As yet I don't know
> why, but it does not overwrite the tmp and tmpdir environment
> variables. However, if I manually issue the commands it is using to
> set these variables they work, so I'm not quite sure why they don't
> from the script. I also think from memory the script was not
> executable by default.

Are you running it as part of the current shell, e.g.
     .  /etc/sysconfig//mysqld
as opposed to
     /etc/sysconfig/mysqld
?  The latter starts a new shell, sets the environment variables there,
and when the script ends the shell ends, taking the changed values with
it.  The former runs the script in the current shell, and any changes
are still there when the script ends.

[Steve Morris-5]

On 02/07/09 11:44, Frank Griffin wrote:

> Steve Morris wrote:
>    
>>> Then realize that you can't create in /root/tmp if you can't cd to
>>> /root, which has perms rwx------.  ;)
>>>
>>>
>>>        
>> If that is the case I am now confused about the inconsistencies is
>> 2009.1. An out of the box install of 2009.1 installs /home not user
>> writeable, but normal users have no issue writing to /home/&uid when
>> /home is left with the default allocations, so what's the difference
>> and why this inconsistency.
>>      
> Execute permission in its normal sense would have no meaning for a
> directory.  So Unix uses it to indicate that you have permission to
> *search* the directory.  This is different from read permission, which
> allows you to read the actual entries.  Search permission allows the
> kernel to search the directory on your behalf, as opposed to read
> permission which allows the kernel to let *you* see the entries yourself.
>    

Yes, and that is the issue with the way msec sets up permissions across

the entire installation if not using the setting that turns security
off. Lots of software, when prompting for directories to start searches
in for whatever is relevant to the function, start in /home and because
of this configuration they show nothing, not even your home directory,
so you can't navigate to that if you want to without a lot of stuffing
around. In other situations there is software that starts in $HOME and
you can't navigate up the tree because you get permission denied failure
on /home unless one manually put the read attribute on other for this
directory, which I have done to bypass this issue.

regards,
Steve


[samorris.vcf]

---

begin:vcard
fn:Steve Morris
n:Morris;Steve
email;internet:samorris@...
x-mozilla-html:TRUE
version:2.1
end:vcard

---

[Steve Morris-5]

On 10/07/09 07:07, Frank Griffin wrote:

> Steve Morris wrote:
>    
>> The /etc/sysconfig.mysqld script doesn't work. As yet I don't know
>> why, but it does not overwrite the tmp and tmpdir environment
>> variables. However, if I manually issue the commands it is using to
>> set these variables they work, so I'm not quite sure why they don't
>> from the script. I also think from memory the script was not
>> executable by default.
>>      
> Are you running it as part of the current shell, e.g.
>       .  /etc/sysconfig//mysqld
> as opposed to
>       /etc/sysconfig/mysqld
> ?  The latter starts a new shell, sets the environment variables there,
> and when the script ends the shell ends, taking the changed values with
> it.  The former runs the script in the current shell, and any changes
> are still there when the script ends.
>    

I was running it the second way. I was not aware that started a new

shell and if so that is a bug, a new shell should only be started if the
& parameter is appended to the end.
Does this only apply to scripts as if I issue /usr/sbin/mysqld from the
current shell, all its cli output appears to be being returned to the
current shell, and, the current shell is not usable for inputing
commands to unless I append the & to the command.

regards,
Steve

>
>    

[samorris.vcf]

---

begin:vcard
fn:Steve Morris
n:Morris;Steve
email;internet:samorris@...
x-mozilla-html:TRUE
version:2.1
end:vcard

---

[Frank Griffin-4]

Steve Morris wrote:

> Yes, and that is the issue with the way msec sets up permissions
> across the entire installation if not using the setting that turns
> security off. Lots of software, when prompting for directories to
> start searches in for whatever is relevant to the function, start in
> /home and because of this configuration they show nothing, not even
> your home directory, so you can't navigate to that if you want to
> without a lot of stuffing around. In other situations there is
> software that starts in $HOME and you can't navigate up the tree
> because you get permission denied failure on /home unless one manually
> put the read attribute on other for this directory, which I have done
> to bypass this issue.

The only problem with your argument is that on MDV systems /home is set
to rwxr-xr-x, which means that normal users can both read and search
it.  The problem you were having was with /root, which is set to
rwx------, meaning that no one but root can read, write, or search it.

[Frank Griffin-4]

Steve Morris wrote:
> I was running it the second way. I was not aware that started a new
> shell and if so that is a bug, a new shell should only be started if
> the & parameter is appended to the end.

No, appending & simply runs the new shell in the background so that you
can continue to enter commands from your primary shell.  With the
exception of builtin commands like cd, all shell scripts executed from a
bash shell execute in a new shell unless you precede it with ". ".

> Does this only apply to scripts as if I issue /usr/sbin/mysqld from
> the current shell, all its cli output appears to be being returned to
> the current shell, and, the current shell is not usable for inputing
> commands to unless I append the & to the command.

You need to read a book on the relationship between processes and
sessions.  A new shell is a new process, but it is still a member of the
same session as your login shell, which owns the console (or terminal)
and has its stdout and stderr directed there.  Executing a new shell
with & will still result in the script's stdout and stderr going to your
terminal unless you specifically redirect it elsewhere.  The only
difference between & and not-& is that with not-& your terminal won't
put up another read until the current command ends.  With &, it does put
up a read, so even though you're seeing stdout and stderr spit out to
the terminal, you can still type new commands.

Try one of the Stevens books.  Those are pretty much the bible for Unix.

[Steve Morris-5]

On 10/07/09 07:48, Frank Griffin wrote:

> Steve Morris wrote:
>    
>> I was running it the second way. I was not aware that started a new
>> shell and if so that is a bug, a new shell should only be started if
>> the&  parameter is appended to the end.
>>      
> No, appending&  simply runs the new shell in the background so that you
> can continue to enter commands from your primary shell.  With the
> exception of builtin commands like cd, all shell scripts executed from a
> bash shell execute in a new shell unless you precede it with ". ".
>    

I knew appending the & subtasked/forked the process, but I was not aware

(mainly because I had never looked) that scripts that have the bash
identifier at the start by default are subtasked in another bash
process, which I assume is purely a bash feature as I have seen
instructions for applications direct to use the & trailer for subtasking
even for scripts, which I assume is because those scripts are generic
and not shell specific.

>    
>> Does this only apply to scripts as if I issue /usr/sbin/mysqld from
>> the current shell, all its cli output appears to be being returned to
>> the current shell, and, the current shell is not usable for inputing
>> commands to unless I append the&  to the command.
>>      
> You need to read a book on the relationship between processes and
> sessions.  A new shell is a new process, but it is still a member of the
> same session as your login shell, which owns the console (or terminal)
> and has its stdout and stderr directed there.  Executing a new shell
> with&  will still result in the script's stdout and stderr going to your
> terminal unless you specifically redirect it elsewhere.  The only
> difference between&  and not-&  is that with not-&  your terminal won't
> put up another read until the current command ends.  With&, it does put
> up a read, so even though you're seeing stdout and stderr spit out to
> the terminal, you can still type new commands.
>    

I fully understand the difference between sessions and processes, and

how stderr and stdout work, and that the stderr and stdout output is
process specific, as evidence by running konsole with multiple tabs or
multiple konsole processes.

regards,
Steve

> Try one of the Stevens books.  Those are pretty much the bible for Unix.
>
>    

[samorris.vcf]

---

begin:vcard
fn:Steve Morris
n:Morris;Steve
email;internet:samorris@...
x-mozilla-html:TRUE
version:2.1
end:vcard

---

[Steve Morris-5]

On 10/07/09 07:33, Frank Griffin wrote:

> Steve Morris wrote:
>    
>> Yes, and that is the issue with the way msec sets up permissions
>> across the entire installation if not using the setting that turns
>> security off. Lots of software, when prompting for directories to
>> start searches in for whatever is relevant to the function, start in
>> /home and because of this configuration they show nothing, not even
>> your home directory, so you can't navigate to that if you want to
>> without a lot of stuffing around. In other situations there is
>> software that starts in $HOME and you can't navigate up the tree
>> because you get permission denied failure on /home unless one manually
>> put the read attribute on other for this directory, which I have done
>> to bypass this issue.
>>      
> The only problem with your argument is that on MDV systems /home is set
> to rwxr-xr-x, which means that normal users can both read and search
> it.  The problem you were having was with /root, which is set to
> rwx------, meaning that no one but root can read, write, or search it.
>    

Not in 2009.1 if msec is told to not use the security setting for an

internet client only. In this environment /home is owned by root:adm
with attributes I think of rwx..x..x (not sure about the last 2 X's,
also group may have read as well, didn't really pay much attention to
that lvl I was more concerned with other) which causes the issues I
outlined above.

regards,
Steve


[samorris.vcf]

---

begin:vcard
fn:Steve Morris
n:Morris;Steve
email;internet:samorris@...
x-mozilla-html:TRUE
version:2.1
end:vcard

---

[Frank Griffin-4]

Steve Morris wrote:
> I knew appending the & subtasked/forked the process, but I was not
> aware (mainly because I had never looked) that scripts that have the
> bash identifier at the start by default are subtasked in another bash
> process, which I assume is purely a bash feature as I have seen
> instructions for applications direct to use the & trailer for
> subtasking even for scripts, which I assume is because those scripts
> are generic and not shell specific.

No, I said bash because that's what we use on MDV, but this behavior is
common to all Unix shells as far as I know.  That's why such shell
commands as "export" exist.

>>  
>>> Does this only apply to scripts as if I issue /usr/sbin/mysqld from
>>> the current shell, all its cli output appears to be being returned to
>>> the current shell, and, the current shell is not usable for inputing
>>> commands to unless I append the&  to the command.
>>>      
>> You need to read a book on the relationship between processes and
>> sessions.  A new shell is a new process, but it is still a member of the
>> same session as your login shell, which owns the console (or terminal)
>> and has its stdout and stderr directed there.  Executing a new shell
>> with&  will still result in the script's stdout and stderr going to your
>> terminal unless you specifically redirect it elsewhere.  The only
>> difference between&  and not-&  is that with not-&  your terminal won't
>> put up another read until the current command ends.  With&, it does put
>> up a read, so even though you're seeing stdout and stderr spit out to
>> the terminal, you can still type new commands.
>>    
> I fully understand the difference between sessions and processes, and
> how stderr and stdout work, and that the stderr and stdout output is
> process specific, as evidence by running konsole with multiple tabs or
> multiple konsole processes.

I don't think you're correct.  stdout/stderr are certainly
process-specific, as you can use shell redirection commands to redirect
them on a per-command basis.  But the default stdout/stderr for any
first-level process in a session is the default for the session, and for
sessions associated with a terminal, that's the terminal.

Konsole with multiple tabs is not the example you want here.  Child
processes inherit the stdout/stderr of their parents by default.  I'm
not certain how konsole arranges its child terminals, but you may be
confusing parent-child inheritance imposed by konsole with the more
general Unix behavior.

If you check out a Unix reference such as the Stevens book I
recommended, you'll find that the business of starting a process from a
terminal and then detaching it so that it survives a terminal logout is
not as simple as you might think.  Certainly not as simple as putting an
ampersand at the end of a command line.

[Frank Griffin-4]

Steve Morris wrote:

> On 10/07/09 07:33, Frank Griffin wrote:    
>> The only problem with your argument is that on MDV systems /home is set
>> to rwxr-xr-x, which means that normal users can both read and search
>> it.  The problem you were having was with /root, which is set to
>> rwx------, meaning that no one but root can read, write, or search it.
>>    
> Not in 2009.1 if msec is told to not use the security setting for an
> internet client only. In this environment /home is owned by root:adm
> with attributes I think of rwx..x..x (not sure about the last 2 X's,
> also group may have read as well, didn't really pay much attention to
> that lvl I was more concerned with other) which causes the issues I
> outlined above.

Well, the devil's in the details.  The x's would permit a path search,
but not a directory listing, which is probably intentional.  In general,
whether it's convenient for you or not, multi-user systems don't usually
encourage different users to be able to read each other's home
directories.  Although I would expect that /home would have ---r--r--
and would leave denying read to the individual user directories.

[Steve Morris-5]

On 13/07/09 12:06, Frank Griffin wrote:

> Steve Morris wrote:
>    
>> I knew appending the&  subtasked/forked the process, but I was not
>> aware (mainly because I had never looked) that scripts that have the
>> bash identifier at the start by default are subtasked in another bash
>> process, which I assume is purely a bash feature as I have seen
>> instructions for applications direct to use the&  trailer for
>> subtasking even for scripts, which I assume is because those scripts
>> are generic and not shell specific.
>>      
> No, I said bash because that's what we use on MDV, but this behavior is
> common to all Unix shells as far as I know.  That's why such shell
> commands as "export" exist.
>
>    
>>>
>>>        
>>>> Does this only apply to scripts as if I issue /usr/sbin/mysqld from
>>>> the current shell, all its cli output appears to be being returned to
>>>> the current shell, and, the current shell is not usable for inputing
>>>> commands to unless I append the&   to the command.
>>>>
>>>>          
>>> You need to read a book on the relationship between processes and
>>> sessions.  A new shell is a new process, but it is still a member of the
>>> same session as your login shell, which owns the console (or terminal)
>>> and has its stdout and stderr directed there.  Executing a new shell
>>> with&   will still result in the script's stdout and stderr going to your
>>> terminal unless you specifically redirect it elsewhere.  The only
>>> difference between&   and not-&   is that with not-&   your terminal won't
>>> put up another read until the current command ends.  With&, it does put
>>> up a read, so even though you're seeing stdout and stderr spit out to
>>> the terminal, you can still type new commands.
>>>
>>>        
>> I fully understand the difference between sessions and processes, and
>> how stderr and stdout work, and that the stderr and stdout output is
>> process specific, as evidence by running konsole with multiple tabs or
>> multiple konsole processes.
>>      
> I don't think you're correct.  stdout/stderr are certainly
> process-specific, as you can use shell redirection commands to redirect
> them on a per-command basis.  But the default stdout/stderr for any
> first-level process in a session is the default for the session, and for
> sessions associated with a terminal, that's the terminal.
>
> Konsole with multiple tabs is not the example you want here.  Child
> processes inherit the stdout/stderr of their parents by default.  I'm
> not certain how konsole arranges its child terminals, but you may be
> confusing parent-child inheritance imposed by konsole with the more
> general Unix behavior.
>    

You might be right, the point I was trying to make is that if you launch

multiple shells, be it konsole, xterm or anything else, the
stdout/stderr "terminal" output is unique to each process in that you
don't get the output from these processes intermingled in a single
"terminal".
As I understand it the tabs in Konsole work the same way as you are
saying bash does, in that each tab is a separate instance of a Konsole
process.
> If you check out a Unix reference such as the Stevens book I
> recommended, you'll find that the business of starting a process from a
> terminal and then detaching it so that it survives a terminal logout is
> not as simple as you might think.  Certainly not as simple as putting an
> ampersand at the end of a command line.
>    
That's ok, I fully understand the complexities of threading, having
dabbled with that in Java and many years ago in C, and mainframe
assembler for OS exits.

regards,
Steve

>
>    

[samorris.vcf]

---

begin:vcard
fn:Steve Morris
n:Morris;Steve
email;internet:samorris@...
x-mozilla-html:TRUE
version:2.1
end:vcard

---

[Steve Morris-5]

On 13/07/09 13:05, Frank Griffin wrote:

> Steve Morris wrote:
>    
>> On 10/07/09 07:33, Frank Griffin wrote:
>>      
>>> The only problem with your argument is that on MDV systems /home is set
>>> to rwxr-xr-x, which means that normal users can both read and search
>>> it.  The problem you were having was with /root, which is set to
>>> rwx------, meaning that no one but root can read, write, or search it.
>>>
>>>        
>> Not in 2009.1 if msec is told to not use the security setting for an
>> internet client only. In this environment /home is owned by root:adm
>> with attributes I think of rwx..x..x (not sure about the last 2 X's,
>> also group may have read as well, didn't really pay much attention to
>> that lvl I was more concerned with other) which causes the issues I
>> outlined above.
>>      
> Well, the devil's in the details.  The x's would permit a path search,
> but not a directory listing, which is probably intentional.  In general,
> whether it's convenient for you or not, multi-user systems don't usually
> encourage different users to be able to read each other's home
> directories.  Although I would expect that /home would have ---r--r--
> and would leave denying read to the individual user directories.
>    

Thats to point I am making, the individual user home directories are not

world readable which is fine, but in the outlined scenario /home has the
same attributes making directory listings (depending on how the are
done) either get permission denied or not display anything, which
includes at this level of hiding the users own home directory.

regards,
Steve


[samorris.vcf]

---

begin:vcard
fn:Steve Morris
n:Morris;Steve
email;internet:samorris@...
x-mozilla-html:TRUE
version:2.1
end:vcard

---