Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
permissions problem.
2 views
Skip to first unread message
The Natural Philosopher
Apr 25, 2012, 11:46:44 AM4/25/12
to
I have a web server whose data srae I routinely NFS mount as a quick way
of shoving data onto it.
The web server has group sticky bits set to force group ownership to
www-data the apache 'user' id.
My desktop here is debian and gnome, but when I drag and drop files
these days - and it never used to be that way - they are appearing as no
read permissions on group so the web server can't access them.
Its easy enough to fix explicitly, but how to set default files saving
in gnome as - say - 644?
Hmm.
further to that it seems that a lot of stuff irrespective of NFS is
appearing with no group read perms - mainly saved web images and
downloaded PDFS and that may be the problem..
If I touch a file its 644.
If I save a file from the document viewer or possible direct from a web
download, its 600
???
--
To people who know nothing, anything is possible.
To people who know too much, it is a sad fact
that they know how little is really possible -
and how hard it is to achieve it.
Message has been deleted
Message has been deleted
Robert Riches
Apr 25, 2012, 11:35:51 PM4/25/12
to
On 2012-04-26, Lew Pitcher <lpit...@teksavvy.com> wrote:
>
> Let's clarify that statement a bit....
>
> umask /takes away/ set permission bits.
> For every 1bit in the umask, the associated permission bit is set to 0
> For every 0bit in the umask, the associated permission bit is left alone
>
> Thus, if your create/open/chmod mode were
> 731
> and you had a umask of
> 365
> you would wind up with permissions of
> 321
>
> mode -> 111 011 001 (731)
> umask -> 011 110 101 (365)
> ====================
> perm -> 011 010 001 (321)
Your explanation and example don't mesh.
--
Robert Riches
spamt...@jacob21819.net
(Yes, that is one of my email addresses.)
>
> Let's clarify that statement a bit....
>
> umask /takes away/ set permission bits.
> For every 1bit in the umask, the associated permission bit is set to 0
> For every 0bit in the umask, the associated permission bit is left alone
>
> Thus, if your create/open/chmod mode were
> 731
> and you had a umask of
> 365
> you would wind up with permissions of
> 321
>
> mode -> 111 011 001 (731)
> umask -> 011 110 101 (365)
> ====================
> perm -> 011 010 001 (321)
Your explanation and example don't mesh.
--
Robert Riches
spamt...@jacob21819.net
(Yes, that is one of my email addresses.)
Lew Pitcher
Apr 26, 2012, 10:41:33 AM4/26/12
to
On Wednesday 25 April 2012 23:35, in comp.os.linux.misc,
Let's try this again....
Thus, if your create/open/chmod mode were
731
and you had a umask of
365
you would wind up with permissions of
414
mode -> 111 011 001 (731)
umask -> 011 110 101 (365)
====================
perm -> 100 001 100 (414)
| | |
+-----+--+-- These bits come from the mode
The rest were zeroed out by umask
--
Lew Pitcher
spamt...@jacob21819.net wrote:
> On 2012-04-26, Lew Pitcher <lpit...@teksavvy.com> wrote:
>>
>> Let's clarify that statement a bit....
>>
>> umask /takes away/ set permission bits.
>> For every 1bit in the umask, the associated permission bit is set to 0
>> For every 0bit in the umask, the associated permission bit is left alone
>>
>> Thus, if your create/open/chmod mode were
>> 731
>> and you had a umask of
>> 365
>> you would wind up with permissions of
>> 321
>>
>> mode -> 111 011 001 (731)
>> umask -> 011 110 101 (365)
>> ====================
>> perm -> 011 010 001 (321)
>
> Your explanation and example don't mesh.
Gawk! You are correct. D*mn, what was I thinking?
> On 2012-04-26, Lew Pitcher <lpit...@teksavvy.com> wrote:
>>
>> Let's clarify that statement a bit....
>>
>> umask /takes away/ set permission bits.
>> For every 1bit in the umask, the associated permission bit is set to 0
>> For every 0bit in the umask, the associated permission bit is left alone
>>
>> Thus, if your create/open/chmod mode were
>> 731
>> and you had a umask of
>> 365
>> you would wind up with permissions of
>> 321
>>
>> mode -> 111 011 001 (731)
>> umask -> 011 110 101 (365)
>> ====================
>> perm -> 011 010 001 (321)
>
> Your explanation and example don't mesh.
Let's try this again....
Thus, if your create/open/chmod mode were
731
and you had a umask of
365
you would wind up with permissions of
mode -> 111 011 001 (731)
umask -> 011 110 101 (365)
====================
| | |
+-----+--+-- These bits come from the mode
The rest were zeroed out by umask
--
Lew Pitcher
unruh
Apr 26, 2012, 12:04:53 PM4/26/12
to
Essenially it is
originalpermission AND(NOT umask)
originalpermission AND(NOT umask)
Sylvain Robitaille
Apr 26, 2012, 12:29:12 PM4/26/12
to
On Thu, 26 Apr 2012 10:41:33 -0400, Lew Pitcher wrote:
> Let's try this again....
>
> Thus, if your create/open/chmod mode were
> 731
> and you had a umask of
> 365
> you would wind up with permissions of
> 414
This caught my eye enough to examine more carefully. My calculation
> Let's try this again....
>
> Thus, if your create/open/chmod mode were
> 731
> and you had a umask of
> 365
> you would wind up with permissions of
> 414
says "410". I'm actually not sure how you figure "414" ...
> mode -> 111 011 001 (731)
> umask -> 011 110 101 (365)
> ====================
> perm -> 100 001 100 (414)
> | | |
> +-----+--+-- These bits come from the mode
> The rest were zeroed out by umask
|
+- where does this one come from? (it isn't in the
original mode setting ...)
unruh's explanation of "mode AND (NOT umask)" is as simple and clear as
I've seen.
--
----------------------------------------------------------------------
Sylvain Robitaille s...@encs.concordia.ca
Systems analyst / AITS Concordia University
Faculty of Engineering and Computer Science Montreal, Quebec, Canada
----------------------------------------------------------------------
Chick Tower
Apr 26, 2012, 3:21:23 PM4/26/12
to
On 2012-04-26, Lew Pitcher <lpit...@teksavvy.com> wrote:
> umask /takes away/ set permission bits.
> For every 1bit in the umask, the associated permission bit is set to 0
> For every 0bit in the umask, the associated permission bit is left alone
>
> umask /takes away/ set permission bits.
> For every 1bit in the umask, the associated permission bit is set to 0
> For every 0bit in the umask, the associated permission bit is left alone
>
> Thus, if your create/open/chmod mode were
> 731
> and you had a umask of
> 365
> you would wind up with permissions of
> 321
> 731
> and you had a umask of
> 365
> you would wind up with permissions of
>
> mode -> 111 011 001 (731)
> umask -> 011 110 101 (365)
> ====================
> perm -> 011 010 001 (321)
> mode -> 111 011 001 (731)
> umask -> 011 110 101 (365)
> ====================
>
I've done no research on this, Lew, but in your example umask seems to
do just the opposite of your description of its effect. Am I
misinterpreting something?
--
Chick Tower
For e-mail: colm DOT sent DOT towerboy AT xoxy DOT net
Robert Riches
Apr 27, 2012, 12:12:11 AM4/27/12
to
0 new messages