Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #7716 > unrolled thread

GUI apps not honoring umask

Back to article view | Back to comp.os.linux.misc

Contents

  GUI apps not honoring umask The Natural Philosopher <tnp@invalid.invalid> - 2013-04-02 19:29 +0100
    Re: GUI apps not honoring umask Lew Pitcher <lpitcher@teksavvy.com> - 2013-04-02 15:03 -0400
      Re: GUI apps not honoring umask Lew Pitcher <lpitcher@teksavvy.com> - 2013-04-02 15:08 -0400
        Re: GUI apps not honoring umask The Natural Philosopher <tnp@invalid.invalid> - 2013-04-02 21:01 +0100
    Re: GUI apps not honoring umask Eli the Bearded <*@eli.users.panix.com> - 2013-04-03 06:27 +0000
      Re: GUI apps not honoring umask The Natural Philosopher <tnp@invalid.invalid> - 2013-04-03 11:01 +0100
        Re: GUI apps not honoring umask Robert Heller <heller@deepsoft.com> - 2013-04-03 06:22 -0500
          Re: GUI apps not honoring umask The Natural Philosopher <tnp@invalid.invalid> - 2013-04-03 12:46 +0100
            Re: GUI apps not honoring umask Robert Heller <heller@deepsoft.com> - 2013-04-03 08:13 -0500
              Re: GUI apps not honoring umask Eli the Bearded <*@eli.users.panix.com> - 2013-04-03 22:13 +0000
                Re: GUI apps not honoring umask The Natural Philosopher <tnp@invalid.invalid> - 2013-04-03 23:45 +0100
                Re: GUI apps not honoring umask Robert Heller <heller@deepsoft.com> - 2013-04-03 17:50 -0500
          Re: GUI apps not honoring umask Chick Tower <c.tower@deadspam.com> - 2013-04-04 17:47 +0000
        Re: GUI apps not honoring umask Jean-David Beyer <jeandavid8@verizon.net> - 2013-04-03 07:27 -0400
          Re: GUI apps not honoring umask The Natural Philosopher <tnp@invalid.invalid> - 2013-04-03 12:48 +0100
            Re: GUI apps not honoring umask Jean-David Beyer <jeandavid8@verizon.net> - 2013-04-03 09:59 -0400
              Re: GUI apps not honoring umask The Natural Philosopher <tnp@invalid.invalid> - 2013-04-03 15:26 +0100
                Re: GUI apps not honoring umask Richard Kettlewell <rjk@greenend.org.uk> - 2013-04-03 15:28 +0100
                Re: GUI apps not honoring umask J G Miller <miller@yoyo.ORG> - 2013-04-03 14:46 +0000
                  Re: GUI apps not honoring umask The Natural Philosopher <tnp@invalid.invalid> - 2013-04-03 17:08 +0100
                    Re: GUI apps not honoring umask J G Miller <miller@yoyo.ORG> - 2013-04-03 16:59 +0000
                      Re: GUI apps not honoring umask The Natural Philosopher <tnp@invalid.invalid> - 2013-04-03 18:45 +0100
                        Re: GUI apps not honoring umask Jean-David Beyer <jeandavid8@verizon.net> - 2013-04-03 14:48 -0400
                          Re: GUI apps not honoring umask The Natural Philosopher <tnp@invalid.invalid> - 2013-04-03 19:56 +0100
                            Re: GUI apps not honoring umask Jean-David Beyer <jeandavid8@verizon.net> - 2013-04-03 15:28 -0400
                            Re: GUI apps not honoring umask Octothorpe <Octothorpe@invalid.com> - 2013-04-03 18:33 -0400
                              Re: GUI apps not honoring umask The Natural Philosopher <tnp@invalid.invalid> - 2013-04-03 23:47 +0100
                                Re: GUI apps not honoring umask Octothorpe <Octothorpe@invalid.com> - 2013-04-03 19:30 -0400
                                  Re: GUI apps not honoring umask Richard Kettlewell <rjk@greenend.org.uk> - 2013-04-04 09:08 +0100
                      Re: GUI apps not honoring umask The Natural Philosopher <tnp@invalid.invalid> - 2013-04-03 18:48 +0100
    Re: GUI apps not honoring umask Bit Twister <BitTwister@mouse-potato.com> - 2013-04-03 11:53 +0000
      Re: GUI apps not honoring umask The Natural Philosopher <tnp@invalid.invalid> - 2013-04-03 13:22 +0100
        Re: GUI apps not honoring umask Bit Twister <BitTwister@mouse-potato.com> - 2013-04-03 12:49 +0000
          Re: GUI apps not honoring umask The Natural Philosopher <tnp@invalid.invalid> - 2013-04-03 15:22 +0100
            Re: GUI apps not honoring umask Bit Twister <BitTwister@mouse-potato.com> - 2013-04-03 21:20 +0000
              Re: GUI apps not honoring umask The Natural Philosopher <tnp@invalid.invalid> - 2013-04-03 22:32 +0100

Page 1 of 2  [1] 2  Next page →

#7716 — GUI apps not honoring umask

Linux mint Mate 13.


Problem. I have a shared server (Linux, NFS mounted with full root 
perms)  and any file I create with any desktop app has 644 perms on it. 
Now the server is well behaved and forces the group to 'staff' and the 
other users are all in group 'staff' but its a real pain in the butt 
when while any console app creates files with umask perms (currently 
664.002) no GUI app does. They seem to overided these.


Anyone got a way around this? I am spending hours of irritable searching 
for files placed there for someone else to edit,. and manually fixing perms.




-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to 
lead are elected by the least capable of producing, and where the 
members of society least likely to sustain themselves or succeed, are 
rewarded with goods and services paid for by the confiscated wealth of a 
diminishing number of producers.

[toc] | [next] | [standalone]

#7717

On Tuesday 02 April 2013 14:29, in comp.os.linux.misc, tnp@invalid.invalid
wrote:

> Linux mint Mate 13.
> 
> 
> Problem. I have a shared server (Linux, NFS mounted with full root
> perms)  and any file I create with any desktop app has 644 perms on it.
> Now the server is well behaved and forces the group to 'staff' and the
> other users are all in group 'staff' but its a real pain in the butt
> when while any console app creates files with umask perms (currently
> 664.002) no GUI app does. They seem to overided these.

I'm not certain I follow you.

You say that
 - gui apps create files with 644 permissions.
 - console apps create files with "umask perms" - 0664 umasked with 002

Well, 0664 permissions, with a umask of 002, results in 0644 permissions

And, isn't that what you are getting? ISTM that your gui apps /are/ using
the given umask.

> Anyone got a way around this? I am spending hours of irritable searching
> for files placed there for someone else to edit,. and manually fixing
> perms.

If you have umask problems in the gui environment, you probably should track
down the script or tool which sets/resets the umask.

In an X environment, look for
  ~/.xinitrc
  ~/.xserverrc
  /usr/lib/X11/xinit/xinitrc
  /usr/lib/X11/xinit/xserverrc

You should probably also read up on your Display Manager (XDM/KDM/GDM/etc),
your window manager and your desktop manager, to see if any of these have
config files or scripts that would alter the umask.

HTH
-- 
Lew Pitcher
"In Skills, We Trust"

[toc] | [prev] | [next] | [standalone]

#7718

On Tuesday 02 April 2013 15:03, in comp.os.linux.misc, lpitcher@teksavvy.com
wrote:

> On Tuesday 02 April 2013 14:29, in comp.os.linux.misc, tnp@invalid.invalid
> wrote:
> 
>> Linux mint Mate 13.
>> 
>> 
>> Problem. I have a shared server (Linux, NFS mounted with full root
>> perms)  and any file I create with any desktop app has 644 perms on it.
>> Now the server is well behaved and forces the group to 'staff' and the
>> other users are all in group 'staff' but its a real pain in the butt
>> when while any console app creates files with umask perms (currently
>> 664.002) no GUI app does. They seem to overided these.
> 
> I'm not certain I follow you.
> 
> You say that
>  - gui apps create files with 644 permissions.
>  - console apps create files with "umask perms" - 0664 umasked with 002
> 
> Well, 0664 permissions, with a umask of 002, results in 0644 permissions

Ack.... I read that with an extra zero (0020) rather than 002 - I get it
now. Your gui is acting as if you had a umask of 0022 rather than 0002.

OK. I get it now


-- 
Lew Pitcher
"In Skills, We Trust"

[toc] | [prev] | [next] | [standalone]

#7719

On 02/04/13 20:08, Lew Pitcher wrote:
> On Tuesday 02 April 2013 15:03, in comp.os.linux.misc, lpitcher@teksavvy.com
> wrote:
>
>> On Tuesday 02 April 2013 14:29, in comp.os.linux.misc, tnp@invalid.invalid
>> wrote:
>>
>>> Linux mint Mate 13.
>>>
>>>
>>> Problem. I have a shared server (Linux, NFS mounted with full root
>>> perms)  and any file I create with any desktop app has 644 perms on it.
>>> Now the server is well behaved and forces the group to 'staff' and the
>>> other users are all in group 'staff' but its a real pain in the butt
>>> when while any console app creates files with umask perms (currently
>>> 664.002) no GUI app does. They seem to overided these.
>>
>> I'm not certain I follow you.
>>
>> You say that
>>   - gui apps create files with 644 permissions.
>>   - console apps create files with "umask perms" - 0664 umasked with 002
>>
>> Well, 0664 permissions, with a umask of 002, results in 0644 permissions
>
> Ack.... I read that with an extra zero (0020) rather than 002 - I get it
> now. Your gui is acting as if you had a umask of 0022 rather than 0002.
>
> OK. I get it now
>
>
I've possibly hacked round it using ACLs..which I didn't know existed.

i.e. i created a 644 file with root perms and deleted it as a user..

I'll look into .xinit etc etc ..

Oh. none of the config files you listed exist.Or any analogs :@-(


But it seems any program can modify up to umask..so setting umask to 
664s wont mean the app does the same.

-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to 
lead are elected by the least capable of producing, and where the 
members of society least likely to sustain themselves or succeed, are 
rewarded with goods and services paid for by the confiscated wealth of a 
diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#7721

In comp.os.linux.misc, The Natural Philosopher  <tnp@invalid.invalid> wrote:
> Problem. I have a shared server (Linux, NFS mounted with full root 
> perms)  and any file I create with any desktop app has 644 perms on it. 
> Now the server is well behaved and forces the group to 'staff' and the 
> other users are all in group 'staff' but its a real pain in the butt 
> when while any console app creates files with umask perms (currently 
> 664.002) no GUI app does. They seem to overided these.

I'm guessing that you set the umask in your shell, but you are not
launching the GUIs from the shell. umask is inherited like the
environment, you must set it very high up the chain to effect
EVERYTHING.

Second thing to consider is umask is a MASK. If a program sets
permissions conservatively in open(), the mask won't help:

$ cat uopen.c
#include <fcntl.h>

int main (void) {

     return open("dude, what's my umask?", O_CREAT, 0600);

}
$ make uopen
cc -O2   -o uopen uopen.c 
$ ls dud*
ls: dud*: No such file or directory
$ umask
0072
$ ./uopen
$ ls -l dud*
-rw-------  1 eli  100  0 Apr  3 02:24 dude, what's my umask?
$ umask
0072
$ 

Elijah
------
umask should be Unix 101

[toc] | [prev] | [next] | [standalone]

#7724

On 03/04/13 07:27, Eli the Bearded wrote:
> In comp.os.linux.misc, The Natural Philosopher  <tnp@invalid.invalid> wrote:
>> Problem. I have a shared server (Linux, NFS mounted with full root
>> perms)  and any file I create with any desktop app has 644 perms on it.
>> Now the server is well behaved and forces the group to 'staff' and the
>> other users are all in group 'staff' but its a real pain in the butt
>> when while any console app creates files with umask perms (currently
>> 664.002) no GUI app does. They seem to overided these.
>
> I'm guessing that you set the umask in your shell, but you are not
> launching the GUIs from the shell. umask is inherited like the
> environment, you must set it very high up the chain to effect
> EVERYTHING.
>

yes...its to discover where the configuration is in fact set for the X 
windows desktop session that is my problem.

> Second thing to consider is umask is a MASK. If a program sets
> permissions conservatively in open(), the mask won't help:
>
Exactly so.

Brute force is to use access control to simply override file perms.

And that is handy because it can be done on a per directory tree.

Which works better in my case of a shared partition on a networked server.

But I'd still like to know how to set the X-window desktop env up with 
the umask I want.



> Elijah
> ------
> umask should be Unix 101
>


-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to 
lead are elected by the least capable of producing, and where the 
members of society least likely to sustain themselves or succeed, are 
rewarded with goods and services paid for by the confiscated wealth of a 
diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#7726

At Wed, 03 Apr 2013 11:01:01 +0100 The Natural Philosopher <tnp@invalid.invalid> wrote:

> 
> On 03/04/13 07:27, Eli the Bearded wrote:
> > In comp.os.linux.misc, The Natural Philosopher  <tnp@invalid.invalid> wrote:
> >> Problem. I have a shared server (Linux, NFS mounted with full root
> >> perms)  and any file I create with any desktop app has 644 perms on it.
> >> Now the server is well behaved and forces the group to 'staff' and the
> >> other users are all in group 'staff' but its a real pain in the butt
> >> when while any console app creates files with umask perms (currently
> >> 664.002) no GUI app does. They seem to overided these.
> >
> > I'm guessing that you set the umask in your shell, but you are not
> > launching the GUIs from the shell. umask is inherited like the
> > environment, you must set it very high up the chain to effect
> > EVERYTHING.
> >
> 
> yes...its to discover where the configuration is in fact set for the X 
> windows desktop session that is my problem.
> 
> > Second thing to consider is umask is a MASK. If a program sets
> > permissions conservatively in open(), the mask won't help:
> >
> Exactly so.
> 
> Brute force is to use access control to simply override file perms.
> 
> And that is handy because it can be done on a per directory tree.
> 
> Which works better in my case of a shared partition on a networked server.
> 
> But I'd still like to know how to set the X-window desktop env up with 
> the umask I want.

"Modern" GUI / Desktops are doing that somewhere in /etc/<mumble>.  Old
school UNIX/X11 did it in .xinitrc (console login + manual startx
[RL3]) or .xsession (GUI login [RL5]). The trend is away from users
defining their own desktop environment "from the ground up" and instead
providing a "standardized" desktop environment, "out of the box" -- a
very MacOS/MS-Windows way of doing things.

> 
> 
> 
> > Elijah
> > ------
> > umask should be Unix 101
> >
> 
> 

-- 
Robert Heller             -- 978-544-6933 / heller@deepsoft.com
Deepwoods Software        -- http://www.deepsoft.com/
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments


                                        

[toc] | [prev] | [next] | [standalone]

#7728

On 03/04/13 12:22, Robert Heller wrote:
> At Wed, 03 Apr 2013 11:01:01 +0100 The Natural Philosopher <tnp@invalid.invalid> wrote:
>
>>
>> On 03/04/13 07:27, Eli the Bearded wrote:
>>> In comp.os.linux.misc, The Natural Philosopher  <tnp@invalid.invalid> wrote:
>>>> Problem. I have a shared server (Linux, NFS mounted with full root
>>>> perms)  and any file I create with any desktop app has 644 perms on it.
>>>> Now the server is well behaved and forces the group to 'staff' and the
>>>> other users are all in group 'staff' but its a real pain in the butt
>>>> when while any console app creates files with umask perms (currently
>>>> 664.002) no GUI app does. They seem to overided these.
>>>
>>> I'm guessing that you set the umask in your shell, but you are not
>>> launching the GUIs from the shell. umask is inherited like the
>>> environment, you must set it very high up the chain to effect
>>> EVERYTHING.
>>>
>>
>> yes...its to discover where the configuration is in fact set for the X
>> windows desktop session that is my problem.
>>
>>> Second thing to consider is umask is a MASK. If a program sets
>>> permissions conservatively in open(), the mask won't help:
>>>
>> Exactly so.
>>
>> Brute force is to use access control to simply override file perms.
>>
>> And that is handy because it can be done on a per directory tree.
>>
>> Which works better in my case of a shared partition on a networked server.
>>
>> But I'd still like to know how to set the X-window desktop env up with
>> the umask I want.
>
> "Modern" GUI / Desktops are doing that somewhere in /etc/<mumble>.  Old
> school UNIX/X11 did it in .xinitrc (console login + manual startx
> [RL3]) or .xsession (GUI login [RL5]). The trend is away from users
> defining their own desktop environment "from the ground up" and instead
> providing a "standardized" desktop environment, "out of the box" -- a
> very MacOS/MS-Windows way of doing things.
>

yes. Thats the perennial problem of trying to give a first time user a 
safe predictable starting point and yet still having the ability to 
configure things for the out of the ordinary situation.

I remember a microsoft commercial installation 'we cant see the network 
server' Windows firewalls everything out by default.
>>
>>
>>
>>> Elijah
>>> ------
>>> umask should be Unix 101
>>>
>>
>>
>


-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to 
lead are elected by the least capable of producing, and where the 
members of society least likely to sustain themselves or succeed, are 
rewarded with goods and services paid for by the confiscated wealth of a 
diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#7733

At Wed, 03 Apr 2013 12:46:41 +0100 The Natural Philosopher <tnp@invalid.invalid> wrote:

> 
> On 03/04/13 12:22, Robert Heller wrote:
> > At Wed, 03 Apr 2013 11:01:01 +0100 The Natural Philosopher <tnp@invalid.invalid> wrote:
> >
> >>
> >> On 03/04/13 07:27, Eli the Bearded wrote:
> >>> In comp.os.linux.misc, The Natural Philosopher  <tnp@invalid.invalid> wrote:
> >>>> Problem. I have a shared server (Linux, NFS mounted with full root
> >>>> perms)  and any file I create with any desktop app has 644 perms on it.
> >>>> Now the server is well behaved and forces the group to 'staff' and the
> >>>> other users are all in group 'staff' but its a real pain in the butt
> >>>> when while any console app creates files with umask perms (currently
> >>>> 664.002) no GUI app does. They seem to overided these.
> >>>
> >>> I'm guessing that you set the umask in your shell, but you are not
> >>> launching the GUIs from the shell. umask is inherited like the
> >>> environment, you must set it very high up the chain to effect
> >>> EVERYTHING.
> >>>
> >>
> >> yes...its to discover where the configuration is in fact set for the X
> >> windows desktop session that is my problem.
> >>
> >>> Second thing to consider is umask is a MASK. If a program sets
> >>> permissions conservatively in open(), the mask won't help:
> >>>
> >> Exactly so.
> >>
> >> Brute force is to use access control to simply override file perms.
> >>
> >> And that is handy because it can be done on a per directory tree.
> >>
> >> Which works better in my case of a shared partition on a networked server.
> >>
> >> But I'd still like to know how to set the X-window desktop env up with
> >> the umask I want.
> >
> > "Modern" GUI / Desktops are doing that somewhere in /etc/<mumble>.  Old
> > school UNIX/X11 did it in .xinitrc (console login + manual startx
> > [RL3]) or .xsession (GUI login [RL5]). The trend is away from users
> > defining their own desktop environment "from the ground up" and instead
> > providing a "standardized" desktop environment, "out of the box" -- a
> > very MacOS/MS-Windows way of doing things.
> >
> 
> yes. Thats the perennial problem of trying to give a first time user a 
> safe predictable starting point and yet still having the ability to 
> configure things for the out of the ordinary situation.

Yes.  The 'old' GUI login [RL5] 'default' was /etc/<mumble>/Xsession,
which created a very minimual desktop: twm + 1 xterm.  Users *promptly*
created a .xsession file (eg by typing emacs or vi in the lone xterm),
with all of the 'right stuff'.  Modern desktops do all sorts of 'fancy'
stuff (launchers, menus, graphical file managers, etc.) and try their
best to discurrage users from creating a .xsession file, since it is
easy for a user to bork themselves with broken syntax, etc. in
.xsession, which results in .xsession crashing, which drops the user
back to the login screen. Users are not expected to understand about
Ctrl-Alt-Fn or using SSH to log in remotely and then fixing .xsession
-- after all the command line is impossibly hard to use -- way too many
*words* (one is forced to use the nasty keyboard thingy) and no
pictures at all -- and noone uses it anymore anyway, since you cannot
point and click at it. :-)


-- 
Robert Heller             -- 978-544-6933 / heller@deepsoft.com
Deepwoods Software        -- http://www.deepsoft.com/
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments


                                                 

[toc] | [prev] | [next] | [standalone]

#7751

In comp.os.linux.misc, Robert Heller  <heller@deepsoft.com> wrote:
> At Wed, 03 Apr 2013 12:46:41 +0100 The Natural Philosopher <tnp@invalid.invalid> wrote:
> > yes. Thats the perennial problem of trying to give a first time user a 
> > safe predictable starting point and yet still having the ability to 
> > configure things for the out of the ordinary situation.
> Yes.  The 'old' GUI login [RL5] 'default' was /etc/<mumble>/Xsession,
> which created a very minimual desktop: twm + 1 xterm.  Users *promptly*

twm? It was Motif when I started. 

> created a .xsession file (eg by typing emacs or vi in the lone xterm),
> with all of the 'right stuff'.  Modern desktops do all sorts of 'fancy'

Many, many people I knew just traded config files with each other. Eg,
more "cp" than "vi". And generally, .xinitrc will take precedence over
.xsession, and give you more control.

> stuff (launchers, menus, graphical file managers, etc.) and try their
> best to discurrage users from creating a .xsession file, since it is
> easy for a user to bork themselves with broken syntax, etc. in
> xsession, which results in .xsession crashing, which drops the user
> back to the login screen.

Login screen? I fuck up my .xinitrc, I get dropped back to /dev/tty1 aka
"console", but I'm not logged out. 

> Ctrl-Alt-Fn or using SSH to log in remotely and then fixing .xsession
> -- after all the command line is impossibly hard to use -- way too many
> *words* (one is forced to use the nasty keyboard thingy) and no
> pictures at all -- and noone uses it anymore anyway, since you cannot
> point and click at it. :-)

This is the same damn trend that makes nano the default editor for root
running "crontab -e" instead of ed.

Elijah
------
ed is worlds better than nano

[toc] | [prev] | [next] | [standalone]

#7752

On 03/04/13 23:13, Eli the Bearded wrote:
> In comp.os.linux.misc, Robert Heller  <heller@deepsoft.com> wrote:
>> At Wed, 03 Apr 2013 12:46:41 +0100 The Natural Philosopher <tnp@invalid.invalid> wrote:
>>> yes. Thats the perennial problem of trying to give a first time user a
>>> safe predictable starting point and yet still having the ability to
>>> configure things for the out of the ordinary situation.
>> Yes.  The 'old' GUI login [RL5] 'default' was /etc/<mumble>/Xsession,
>> which created a very minimual desktop: twm + 1 xterm.  Users *promptly*
>
> twm? It was Motif when I started.
>
>> created a .xsession file (eg by typing emacs or vi in the lone xterm),
>> with all of the 'right stuff'.  Modern desktops do all sorts of 'fancy'
>
> Many, many people I knew just traded config files with each other. Eg,
> more "cp" than "vi". And generally, .xinitrc will take precedence over
> .xsession, and give you more control.
>
>> stuff (launchers, menus, graphical file managers, etc.) and try their
>> best to discurrage users from creating a .xsession file, since it is
>> easy for a user to bork themselves with broken syntax, etc. in
>> xsession, which results in .xsession crashing, which drops the user
>> back to the login screen.
>
> Login screen? I fuck up my .xinitrc, I get dropped back to /dev/tty1 aka
> "console", but I'm not logged out.
>
>> Ctrl-Alt-Fn or using SSH to log in remotely and then fixing .xsession
>> -- after all the command line is impossibly hard to use -- way too many
>> *words* (one is forced to use the nasty keyboard thingy) and no
>> pictures at all -- and noone uses it anymore anyway, since you cannot
>> point and click at it. :-)
>
> This is the same damn trend that makes nano the default editor for root
> running "crontab -e" instead of ed.
>

In my day you hand carved the runes with a hunting knife....
> Elijah
> ------
> ed is worlds better than nano
>


-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to 
lead are elected by the least capable of producing, and where the 
members of society least likely to sustain themselves or succeed, are 
rewarded with goods and services paid for by the confiscated wealth of a 
diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#7755

At Wed, 3 Apr 2013 22:13:09 +0000 (UTC) Eli the Bearded <*@eli.users.panix.com> wrote:

> 
> In comp.os.linux.misc, Robert Heller  <heller@deepsoft.com> wrote:
> > At Wed, 03 Apr 2013 12:46:41 +0100 The Natural Philosopher <tnp@invalid.invalid> wrote:
> > > yes. Thats the perennial problem of trying to give a first time user a 
> > > safe predictable starting point and yet still having the ability to 
> > > configure things for the out of the ordinary situation.
> > Yes.  The 'old' GUI login [RL5] 'default' was /etc/<mumble>/Xsession,
> > which created a very minimual desktop: twm + 1 xterm.  Users *promptly*
> 
> twm? It was Motif when I started. 

twm on SunOS 3 (long before Solaris was even dreamed up), 'DECWindows'
on VMS (VAXStation2000 and VAXStation3000) and Ultrix (DECStations). 
DECWindows = DEC's re-branded Motif. (And yes, I use fvwm in MWM [Motif
Window Manager] compatibility mode and a home-brewed session manager
that is something of a clone of DEC's original DECWindows Session
Manager.  Oh, and I use a LK450 keyboard (like a VT220 keyboard, but
PS2) and a three button mouse (no scrollwheel abomination) -- *my*
desktop is little changed from what it was ~35 years ago -- mostly it
has colors now -- the VAXStation2000s were B&W.)

> 
> > created a .xsession file (eg by typing emacs or vi in the lone xterm),
> > with all of the 'right stuff'.  Modern desktops do all sorts of 'fancy'
> 
> Many, many people I knew just traded config files with each other. Eg,
> more "cp" than "vi". And generally, .xinitrc will take precedence over
> .xsession, and give you more control.

Sure, and cp can be thought of as a brute force V0 editor... :-)

> 
> > stuff (launchers, menus, graphical file managers, etc.) and try their
> > best to discurrage users from creating a .xsession file, since it is
> > easy for a user to bork themselves with broken syntax, etc. in
> > xsession, which results in .xsession crashing, which drops the user
> > back to the login screen.
> 
> Login screen? I fuck up my .xinitrc, I get dropped back to /dev/tty1 aka
> "console", but I'm not logged out. 

It is called Runlevel 3.  'Modern' machines go to Runlevel 5 (by
default) and display a 'pretty' X11 login screen.  Yech.  *My* machines
go to Runlevel 3 and my login conditionally runs startx.  Sometimes you
feel like a GUI, sometimes you don't -- for quick little stuff there is
little point in firing up the whole GUI desktop -- get on, fire up the
text editor, change one little thing and done.

> 
> > Ctrl-Alt-Fn or using SSH to log in remotely and then fixing .xsession
> > -- after all the command line is impossibly hard to use -- way too many
> > *words* (one is forced to use the nasty keyboard thingy) and no
> > pictures at all -- and noone uses it anymore anyway, since you cannot
> > point and click at it. :-)
> 
> This is the same damn trend that makes nano the default editor for root
> running "crontab -e" instead of ed.
> 
> Elijah
> ------
> ed is worlds better than nano
>                                                                                               

-- 
Robert Heller             -- 978-544-6933 / heller@deepsoft.com
Deepwoods Software        -- http://www.deepsoft.com/
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments


                                         

[toc] | [prev] | [next] | [standalone]

#7763

On 2013-04-03, Robert Heller <heller@deepsoft.com> wrote:
> "Modern" GUI / Desktops are doing that somewhere in /etc/<mumble>.  Old
> school UNIX/X11 did it in .xinitrc (console login + manual startx
> [RL3]) or .xsession (GUI login [RL5]). The trend is away from users
> defining their own desktop environment "from the ground up" and instead
> providing a "standardized" desktop environment, "out of the box" -- a
> very MacOS/MS-Windows way of doing things.

Well, they could have put .xinitrc and .xsession in /etc/skel.  Problem
solved without any extra code in the WM/DE.
-- 
                                 Chick Tower

For e-mail:  colm DOT sent DOT towerboy AT xoxy DOT net

[toc] | [prev] | [next] | [standalone]

#7727

On 04/03/2013 06:01 AM, The Natural Philosopher wrote:
> On 03/04/13 07:27, Eli the Bearded wrote:
>> In comp.os.linux.misc, The Natural Philosopher  <tnp@invalid.invalid>
>> wrote:
>>> Problem. I have a shared server (Linux, NFS mounted with full root
>>> perms)  and any file I create with any desktop app has 644 perms on it.
>>> Now the server is well behaved and forces the group to 'staff' and the
>>> other users are all in group 'staff' but its a real pain in the butt
>>> when while any console app creates files with umask perms (currently
>>> 664.002) no GUI app does. They seem to overided these.
>>
>> I'm guessing that you set the umask in your shell, but you are not
>> launching the GUIs from the shell. umask is inherited like the
>> environment, you must set it very high up the chain to effect
>> EVERYTHING.
>>
> 
> yes...its to discover where the configuration is in fact set for the X
> windows desktop session that is my problem.
> 
>> Second thing to consider is umask is a MASK. If a program sets
>> permissions conservatively in open(), the mask won't help:
>>
> Exactly so.
> 
> Brute force is to use access control to simply override file perms.
> 
> And that is handy because it can be done on a per directory tree.
> 
> Which works better in my case of a shared partition on a networked server.
> 
> But I'd still like to know how to set the X-window desktop env up with
> the umask I want.
> 

Since I usually run with X-window system, I put stuff like that in my
~/.bashrc file. E.g.,


DellT7600:jeandavid8[~]$ cat .bashrc
# .bashrc

# Source global definitions
if [ -f /etc/bashrc ]; then
	. /etc/bashrc
fi

# Added by Jean-David Beyer
PS1="\h:\u[\w]\\$ "

alias c=clear

umask 027

# User specific aliases and functions
GPG_TTY=$(tty)
export GPG_TTY

EDITOR=emacs
export EDITOR

[toc] | [prev] | [next] | [standalone]

#7729

On 03/04/13 12:27, Jean-David Beyer wrote:
> On 04/03/2013 06:01 AM, The Natural Philosopher wrote:
>> On 03/04/13 07:27, Eli the Bearded wrote:
>>> In comp.os.linux.misc, The Natural Philosopher  <tnp@invalid.invalid>
>>> wrote:
>>>> Problem. I have a shared server (Linux, NFS mounted with full root
>>>> perms)  and any file I create with any desktop app has 644 perms on it.
>>>> Now the server is well behaved and forces the group to 'staff' and the
>>>> other users are all in group 'staff' but its a real pain in the butt
>>>> when while any console app creates files with umask perms (currently
>>>> 664.002) no GUI app does. They seem to overided these.
>>>
>>> I'm guessing that you set the umask in your shell, but you are not
>>> launching the GUIs from the shell. umask is inherited like the
>>> environment, you must set it very high up the chain to effect
>>> EVERYTHING.
>>>
>>
>> yes...its to discover where the configuration is in fact set for the X
>> windows desktop session that is my problem.
>>
>>> Second thing to consider is umask is a MASK. If a program sets
>>> permissions conservatively in open(), the mask won't help:
>>>
>> Exactly so.
>>
>> Brute force is to use access control to simply override file perms.
>>
>> And that is handy because it can be done on a per directory tree.
>>
>> Which works better in my case of a shared partition on a networked server.
>>
>> But I'd still like to know how to set the X-window desktop env up with
>> the umask I want.
>>
>
> Since I usually run with X-window system, I put stuff like that in my
> ~/.bashrc file. E.g.,
>
>
> DellT7600:jeandavid8[~]$ cat .bashrc
> # .bashrc
>
> # Source global definitions
> if [ -f /etc/bashrc ]; then
> 	. /etc/bashrc
> fi
>
> # Added by Jean-David Beyer
> PS1="\h:\u[\w]\\$ "
>
> alias c=clear
>
> umask 027
>
> # User specific aliases and functions
> GPG_TTY=$(tty)
> export GPG_TTY
>
> EDITOR=emacs
> export EDITOR
>
this makes no real difference to me at all.

all shell spawned stuff and console apps honour this, but nothing 
launched from a GUI does.

Its as if the mate window manager has set its own umask

-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to 
lead are elected by the least capable of producing, and where the 
members of society least likely to sustain themselves or succeed, are 
rewarded with goods and services paid for by the confiscated wealth of a 
diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#7734

On 04/03/2013 07:48 AM, The Natural Philosopher wrote:
> On 03/04/13 12:27, Jean-David Beyer wrote:
>> On 04/03/2013 06:01 AM, The Natural Philosopher wrote:
>>> On 03/04/13 07:27, Eli the Bearded wrote:
>>>> In comp.os.linux.misc, The Natural Philosopher  <tnp@invalid.invalid>
>>>> wrote:
>>>>> Problem. I have a shared server (Linux, NFS mounted with full root
>>>>> perms)  and any file I create with any desktop app has 644 perms on
>>>>> it.
>>>>> Now the server is well behaved and forces the group to 'staff' and the
>>>>> other users are all in group 'staff' but its a real pain in the butt
>>>>> when while any console app creates files with umask perms (currently
>>>>> 664.002) no GUI app does. They seem to overided these.
>>>>
>>>> I'm guessing that you set the umask in your shell, but you are not
>>>> launching the GUIs from the shell. umask is inherited like the
>>>> environment, you must set it very high up the chain to effect
>>>> EVERYTHING.
>>>>
>>>
>>> yes...its to discover where the configuration is in fact set for the X
>>> windows desktop session that is my problem.
>>>
>>>> Second thing to consider is umask is a MASK. If a program sets
>>>> permissions conservatively in open(), the mask won't help:
>>>>
>>> Exactly so.
>>>
>>> Brute force is to use access control to simply override file perms.
>>>
>>> And that is handy because it can be done on a per directory tree.
>>>
>>> Which works better in my case of a shared partition on a networked
>>> server.
>>>
>>> But I'd still like to know how to set the X-window desktop env up with
>>> the umask I want.
>>>
>>
>> Since I usually run with X-window system, I put stuff like that in my
>> ~/.bashrc file. E.g.,
>>
>>
>> DellT7600:jeandavid8[~]$ cat .bashrc
>> # .bashrc
>>
>> # Source global definitions
>> if [ -f /etc/bashrc ]; then
>>     . /etc/bashrc
>> fi
>>
>> # Added by Jean-David Beyer
>> PS1="\h:\u[\w]\\$ "
>>
>> alias c=clear
>>
>> umask 027
>>
>> # User specific aliases and functions
>> GPG_TTY=$(tty)
>> export GPG_TTY
>>
>> EDITOR=emacs
>> export EDITOR
>>
> this makes no real difference to me at all.
> 
> all shell spawned stuff and console apps honour this, but nothing
> launched from a GUI does.

It works for me. If I run an xterm -- that is launched from the GUI that
is my desktop -- my umask works. If I run Firefox, and have it save a
file, it works.

I forgot to say that my .bash_profile has this in it, so just about
everything sees the .bashrc:

$ cat .bash_profile
# .bash_profile

# Get the aliases and functions
if [ -f ~/.bashrc ]; then
	. ~/.bashrc
fi

etc.
> 
> Its as if the mate window manager has set its own umask
> 

[toc] | [prev] | [next] | [standalone]

#7736

On 03/04/13 14:59, Jean-David Beyer wrote:
> On 04/03/2013 07:48 AM, The Natural Philosopher wrote:
>> On 03/04/13 12:27, Jean-David Beyer wrote:
>>> On 04/03/2013 06:01 AM, The Natural Philosopher wrote:
>>>> On 03/04/13 07:27, Eli the Bearded wrote:
>>>>> In comp.os.linux.misc, The Natural Philosopher  <tnp@invalid.invalid>
>>>>> wrote:
>>>>>> Problem. I have a shared server (Linux, NFS mounted with full root
>>>>>> perms)  and any file I create with any desktop app has 644 perms on
>>>>>> it.
>>>>>> Now the server is well behaved and forces the group to 'staff' and the
>>>>>> other users are all in group 'staff' but its a real pain in the butt
>>>>>> when while any console app creates files with umask perms (currently
>>>>>> 664.002) no GUI app does. They seem to overided these.
>>>>>
>>>>> I'm guessing that you set the umask in your shell, but you are not
>>>>> launching the GUIs from the shell. umask is inherited like the
>>>>> environment, you must set it very high up the chain to effect
>>>>> EVERYTHING.
>>>>>
>>>>
>>>> yes...its to discover where the configuration is in fact set for the X
>>>> windows desktop session that is my problem.
>>>>
>>>>> Second thing to consider is umask is a MASK. If a program sets
>>>>> permissions conservatively in open(), the mask won't help:
>>>>>
>>>> Exactly so.
>>>>
>>>> Brute force is to use access control to simply override file perms.
>>>>
>>>> And that is handy because it can be done on a per directory tree.
>>>>
>>>> Which works better in my case of a shared partition on a networked
>>>> server.
>>>>
>>>> But I'd still like to know how to set the X-window desktop env up with
>>>> the umask I want.
>>>>
>>>
>>> Since I usually run with X-window system, I put stuff like that in my
>>> ~/.bashrc file. E.g.,
>>>
>>>
>>> DellT7600:jeandavid8[~]$ cat .bashrc
>>> # .bashrc
>>>
>>> # Source global definitions
>>> if [ -f /etc/bashrc ]; then
>>>      . /etc/bashrc
>>> fi
>>>
>>> # Added by Jean-David Beyer
>>> PS1="\h:\u[\w]\\$ "
>>>
>>> alias c=clear
>>>
>>> umask 027
>>>
>>> # User specific aliases and functions
>>> GPG_TTY=$(tty)
>>> export GPG_TTY
>>>
>>> EDITOR=emacs
>>> export EDITOR
>>>
>> this makes no real difference to me at all.
>>
>> all shell spawned stuff and console apps honour this, but nothing
>> launched from a GUI does.
>
> It works for me. If I run an xterm -- that is launched from the GUI that
> is my desktop -- my umask works. If I run Firefox, and have it save a
> file, it works.
>

oh xterms work, because they spawn a bash shell that sets the umask.

Its stuff that is point and clicky spawned by the dekstop manager 
directly that does not.

> I forgot to say that my .bash_profile has this in it, so just about
> everything sees the .bashrc:
>
> $ cat .bash_profile
> # .bash_profile
>
> # Get the aliases and functions
> if [ -f ~/.bashrc ]; then
> 	. ~/.bashrc
> fi
>

Again all this is correct in my case and works for anything run under a 
console app that has a shell.

What doesn't work is stuff spawned by the *desktop itself* with no shell 
at all.

> etc.
>>
>> Its as if the mate window manager has set its own umask
>>
>


-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to 
lead are elected by the least capable of producing, and where the 
members of society least likely to sustain themselves or succeed, are 
rewarded with goods and services paid for by the confiscated wealth of a 
diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#7737

The Natural Philosopher <tnp@invalid.invalid> writes:
> What doesn't work is stuff spawned by the *desktop itself* with no
> shell at all.

pam_umask might work (I’ve not tried it myself).

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

[toc] | [prev] | [next] | [standalone]

#7738

On Wednesday, April 3rd, 2013, at 15:26:25h +0100, The Natural Philosopher wrote:

> What doesn't work is stuff spawned by the *desktop itself* with no shell 
> at all.

Have you checked in /etc/login.defs for the umask value there for 
the initial process in the login process hierarchy.

[toc] | [prev] | [next] | [standalone]

#7739

On 03/04/13 15:46, J G Miller wrote:
> On Wednesday, April 3rd, 2013, at 15:26:25h +0100, The Natural Philosopher wrote:
>
>> What doesn't work is stuff spawned by the *desktop itself* with no shell
>> at all.
>
> Have you checked in /etc/login.defs for the umask value there for
> the initial process in the login process hierarchy.
>
already changed that. No luck there either.

It seems this is a bug in the code that doesn't honor umask values set 
ANYWHERE.

Everything works fine as a *bash/console* users. All these suggestions work.

NOTHING affects programs spawned from the window manager

the bug report appears to suggest that it also ignores Richards 
suggestion of setting pam_umask as well.

It looks as though mdm sets its own umask irrespective of other settings.

-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to 
lead are elected by the least capable of producing, and where the 
members of society least likely to sustain themselves or succeed, are 
rewarded with goods and services paid for by the confiscated wealth of a 
diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.os.linux.misc

csiph-web