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

[Frank Griffin-4]

Steve Morris wrote:
> 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".

That's because konsole, xterm, et al. are actively capturing each
process' stdout/stderr and directing it to code that writes it to the
associated terminal window.  If you launch several scripts from the same
terminal window using &, you'll see the different outputs intermingled
in that window.

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

Threading isn't the issue.  The problem is detaching a process from one
session/process-group and adding it to another, so that when the
original process-group or session ends, the process doesn't.  The
general technique is to add the process to the a "init" process-group,
but it takes several fairly convoluted system calls to do this.

[Frank Griffin-4]

Steve Morris wrote:

> On 13/07/09 13:05, Frank Griffin wrote:
>> Steve Morris wrote:
>>  
>>> 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.

What tool(s) start their filechoosers in /home ?  And do they do it by
default or because of something you set ?  Everything used to start in
the user's home directory, and then the desktops went all
turnip-friendly and started things in ~/Documents.  But I've never come
across anything that starts in /home, nor can I think of a reason for it to.

[Steve Morris-5]

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

> Steve Morris wrote:
>    
>> 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".
>>      
> That's because konsole, xterm, et al. are actively capturing each
> process' stdout/stderr and directing it to code that writes it to the
> associated terminal window.  If you launch several scripts from the same
> terminal window using&, you'll see the different outputs intermingled
> in that window.
>    

Exactly, the stderr/stdout environments are process specific not just

session specific, unless in your terminology you are calling an instance
of a shell a session. I don't, I call the tty environment a session and
everything that is running in that tty session a process, and each
process has its own stdout/stderr environment and whether or not
anything is displayed from that environment is determined by where they
choose to redirect that output, you don't have just 1 stdout/stderr for
the entire session.

>>> 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.
>>
>>      
> Threading isn't the issue.  The problem is detaching a process from one
> session/process-group and adding it to another, so that when the
> original process-group or session ends, the process doesn't.  The
> general technique is to add the process to the a "init" process-group,
> but it takes several fairly convoluted system calls to do this.
>    

Agreed, and I would say that is a design failing in the Linux Architecture.

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 14/07/09 11:03, Frank Griffin wrote:

> Steve Morris wrote:
>    
>> On 13/07/09 13:05, Frank Griffin wrote:
>>      
>>> Steve Morris wrote:
>>>
>>>        
>>>> 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.
>>      
> What tool(s) start their filechoosers in /home ?  And do they do it by
> default or because of something you set ?  Everything used to start in
> the user's home directory, and then the desktops went all
> turnip-friendly and started things in ~/Documents.  But I've never come
> across anything that starts in /home, nor can I think of a reason for it to.
>    

I will take note of which applications are doing this. As far as I am

aware it is nothing I have set, as far as I am aware it is inherent
functionality in an out of the box install of 2009.1 when 1 sets that
security level in msec during the install. There are also applications
that when starting in the users home environment, if you use the '..' to
navigate up the tree fail because /home is not readable and leave you
sitting in the users 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

---

[Frank Griffin-4]

Steve Morris wrote:

> On 14/07/09 10:16, Frank Griffin wrote:
>> That's because konsole, xterm, et al. are actively capturing each
>> process' stdout/stderr and directing it to code that writes it to the
>> associated terminal window.  If you launch several scripts from the same
>> terminal window using&, you'll see the different outputs intermingled
>> in that window.
>>    
> Exactly, the stderr/stdout environments are process specific not just
> session specific, unless in your terminology you are calling an
> instance of a shell a session. I don't, I call the tty environment a
> session and everything that is running in that tty session a process,
> and each process has its own stdout/stderr environment and whether or
> not anything is displayed from that environment is determined by where
> they choose to redirect that output, you don't have just 1
> stdout/stderr for the entire session.

I didn't say you did.  If you redirect at a process level, they'll go
where you redirect them.  If you don't, they'll inherit from the parent
process.  If you don't redirect and none of the parents redirect,
they'll go to the session.

You're assuming that each konsole terminal you see is a separate
session, and it's probably not.  Under GNOME, if you open several
terminal windows, even from the menu choice as opposed to File -> Open
Terminal, and then do a "ps gx -H", you'll see that all of them are
children of a single gnome-terminal process.

As I said, the process which runs each terminal image has its
stdout/stderr explicitly redirected to print on that terminal image.  If
you type shell commands in a terminal image using ">" to redirect their
output, the output will go where it's directed.  If you *don't* use ">",
the output will go by default to the same location as the parent, which
is the terminal image.

That's why commands you issue in different terminal images without
redirection go to those terminal images, and why multiple commands
issued with no redirection and & in a single terminal image will all go
to that terminal image and be intermingled.


>> Threading isn't the issue.  The problem is detaching a process from one
>> session/process-group and adding it to another, so that when the
>> original process-group or session ends, the process doesn't.  The
>> general technique is to add the process to the a "init" process-group,
>> but it takes several fairly convoluted system calls to do this.
>>    
> Agreed, and I would say that is a design failing in the Linux
> Architecture.

It's not specific to Linux, and it's by design.  The original intent in
Unix was that if a console terminal user logged off, i.e. terminated his
session, then all processes in that session would be killed and not left
around.

It's hardly a failing that moving a process is possible, though
difficult.  In fact, other multitasking OS's don't allow it at all.  Try
attaching a subtask in z/OS and then telling the nucleus that you want
it to be a subtask of some other address space.  Not possible.  Of
course, you could schedule an SRB to the other address space to schedule
an IRB to the desired parent task and issue the ATTACH there, but that's
about ten times more complicated than the Unix procedure to move a
process to a different session.


>
> regards,
> Steve
>
>