RE: ACL Problem in SL7.2

2016-11-08 Thread Bill Maidment 
Wow. Thanks everyone for your insights and suggestions.
After more thinking and tests, it could be that RedHat are closing in on a 
solution with https://access.redhat.com/solutions/447803 (I'm not a subscriber 
either).

For me the current situation is not ideal but usable.
Adding directories through Nautilus gives the correct permissions inherited 
down from the top directory, but adding a file adds a gratuitous read on Other.
As the share is restricted to a particular group of users, it is no real issue 
for me.

Thanks again everyone. I'll await any further developments from RedHat.
Bill
 
-Original message-
> From:Karel Lang AFD 
> Sent: Tuesday 8th November 2016 21:22
> To: Bill Maidment ; SCIENTIFIC-LINUX-USERS@FNAL.GOV
> Subject: Re: ACL Problem in SL7.2
> 
> Hi Bill,
> 
> problem indeed.
> Just suggestion/question - the NFS client running on SL 6.x is 
> configured to use also NFSv4 protocol? Eg.
> 
> mount -t nfs -o vers=4 server:/data /tmp
> 
> btw i think Red Hat been solving something similar here:
> 
> 'NFS client using NFSv4 ACLs loses the correct mask of a newly created 
> file in subdirectories'
> 
> https://access.redhat.com/solutions/447803
> 
> unfortunately 'subscriber content' which i'm not, maybe you? :-)
> 
> 
> On 11/08/2016 06:19 AM, Bill Maidment wrote:
> > Hi again
> > My research has revealed that nfs in SL 7.2 is translating the POSIX ACL to 
> > NFSv4 ACL (a completely different format).
> > vi appears to recognise NFSv4 ACL, but Nautilus, ls and probably other 
> > programs, only seem to recognise POSIX ACL.
> >
> > So I have the following alternatives:
> > 1. Stop nfs translating to NFSv4 ACL
> > 2. Change the guest mount to translate NFSv4 ACL back to POSIX ACL
> > 3. Change Nautilus, etc to recognise NFSv4 ACL
> > 4. Use Samba instead of nfs
> >
> > I'm not sure if 1. or 2. are possible and 3. may happen one day. Does 
> > anyone know of a practical solution/workaround?
> > Cheers
> > Bill
> >
> > -Original message-
> >> From:Bill Maidment 
> >> Sent: Sunday 6th November 2016 19:56
> >> To: Karel Lang AFD ; SCIENTIFIC-LINUX-USERS@FNAL.GOV
> >> Subject: RE: ACL Problem in SL7.2
> >>
> >> Thanks for the response Karel.
> >> umask is the standard 0022 and this is a top level directory on the host 
> >> machine.
> >> I am using SL 6.8 to access the directory via nfs share.
> >> It looks like there is no problem if the file is created with vi
> >> But if I use Nautilus then that's when I get the issue.
> >> So Nautilus on SL 6.8 seems to be the culprit (or is it caused by nfs?)
> >> Cheers
> >> Bill
> >>
> >> -Original message-
> >>> From:Karel Lang AFD 
> >>> Sent: Sunday 6th November 2016 16:16
> >>> To: Bill Maidment ; SCIENTIFIC-LINUX-USERS@FNAL.GOV
> >>> Subject: Re: ACL Problem in SL7.2
> >>>
> >>> Hi Bill
> >>> just pasted your work here to CLI and works OK on SL 6.7 and SL 7.2 
> >>> here...
> >>> It has to be something else .. umask? or inherited from directory higher 
> >>> up?
> >>> Maybe strace would help to see whats happening exactly?
> >>>
> >>> cheers
> >>>
> >>> On 11/06/2016 03:58 AM, Bill Maidment wrote:
>  Hi
>  I am trying to set up ACL on a directory such that any new file created 
>  in the directory has permissions of 0660.
>  However, when I create a new file, the permissions are set as 0664 (see 
>  test.txt file below)
>  Is this a bug or am I doing something wrong?
> 
>  These are the commands I used:
> 
>  chmod -R u+rwX,g+rwXs,o-rwx /pictures
> 
>  setfacl -d -m u::rwx,g::rwx,o::--- /pictures
> 
>  getfacl /pictures
>  getfacl: Removing leading '/' from absolute path names
>  # file: pictures
>  # owner: nfs01
>  # group: nfs01
>  # flags: -s-
>  user::rwx
>  group::rwx
>  other::---
>  default:user::rwx
>  default:group::rwx
>  default:other::---
> 
>  ls -latrh /pictures
>  total 4.0K
>  dr-xr-xr-x. 22 root  root  4.0K Nov  6 12:41 ..
>  drwxrws---+  2 nfs01 nfs01   21 Nov  6 13:10 Testing
>  -rw-rw-r--   1 nfs01 nfs01    0 Nov  6 13:44 test.txt
>  drwxrws---+  3 nfs01 nfs01   35 Nov  6 13:44 .
> 
>  Cheers
>  Bill Maidment
> 
> >>>
> >>>
> >>
> >>
> >
> 
> -- 
> *Karel Lang*
> *Unix/Linux Administration*
> l...@afd.cz | +420 731 13 40 40
> AUFEER DESIGN, s.r.o. | www.aufeerdesign.cz
> 
>

Re: ACL Problem in SL7.2

2016-11-08 Thread Nico Kadel-Garcia 
On Tue, Nov 8, 2016 at 12:19 AM, Bill Maidment  wrote:
> Hi again
> My research has revealed that nfs in SL 7.2 is translating the POSIX ACL to 
> NFSv4 ACL (a completely different format).
> vi appears to recognise NFSv4 ACL, but Nautilus, ls and probably other 
> programs, only seem to recognise POSIX ACL.

Ohh. *ouch*. NFSv4 permission management is well, it's ugly, for
both NFS and for CIFS.

> So I have the following alternatives:
> 1. Stop nfs translating to NFSv4 ACL
> 2. Change the guest mount to translate NFSv4 ACL back to POSIX ACL
> 3. Change Nautilus, etc to recognise NFSv4 ACL
> 4. Use Samba instead of nfs

Samba is server software. The protocol you're referring to, whether
the upstream is a Samba or Windows server, is CIFS, and the clients
are generally in the somewhat independent toolkit cifs-utils, and CIFS
would mean well, a lot of differences, including but not limited
to a *very* chatty protocol with far inferior performance.

> I'm not sure if 1. or 2. are possible and 3. may happen one day. Does anyone 
> know of a practical solution/workaround?
> Cheers
> Bill

If feasible, I'd switch to resetting the default mount behavior to be
NFSv3 based, not NFSv4. NFSv4 has a stack of potentially useful
features, such as using Kerberos credentials instead of simply system
uid for access control. In fact, I wonder if that's part of the issue?
Do you have some Kerberized credentials in play here?


> -Original message-
>> From:Bill Maidment 
>> Sent: Sunday 6th November 2016 19:56
>> To: Karel Lang AFD ; SCIENTIFIC-LINUX-USERS@FNAL.GOV
>> Subject: RE: ACL Problem in SL7.2
>>
>> Thanks for the response Karel.
>> umask is the standard 0022 and this is a top level directory on the host 
>> machine.
>> I am using SL 6.8 to access the directory via nfs share.
>> It looks like there is no problem if the file is created with vi
>> But if I use Nautilus then that's when I get the issue.
>> So Nautilus on SL 6.8 seems to be the culprit (or is it caused by nfs?)
>> Cheers
>> Bill
>>
>> -Original message-
>> > From:Karel Lang AFD 
>> > Sent: Sunday 6th November 2016 16:16
>> > To: Bill Maidment ; SCIENTIFIC-LINUX-USERS@FNAL.GOV
>> > Subject: Re: ACL Problem in SL7.2
>> >
>> > Hi Bill
>> > just pasted your work here to CLI and works OK on SL 6.7 and SL 7.2 here...
>> > It has to be something else .. umask? or inherited from directory higher 
>> > up?
>> > Maybe strace would help to see whats happening exactly?
>> >
>> > cheers
>> >
>> > On 11/06/2016 03:58 AM, Bill Maidment wrote:
>> > > Hi
>> > > I am trying to set up ACL on a directory such that any new file created 
>> > > in the directory has permissions of 0660.
>> > > However, when I create a new file, the permissions are set as 0664 (see 
>> > > test.txt file below)
>> > > Is this a bug or am I doing something wrong?
>> > >
>> > > These are the commands I used:
>> > >
>> > > chmod -R u+rwX,g+rwXs,o-rwx /pictures
>> > >
>> > > setfacl -d -m u::rwx,g::rwx,o::--- /pictures
>> > >
>> > > getfacl /pictures
>> > > getfacl: Removing leading '/' from absolute path names
>> > > # file: pictures
>> > > # owner: nfs01
>> > > # group: nfs01
>> > > # flags: -s-
>> > > user::rwx
>> > > group::rwx
>> > > other::---
>> > > default:user::rwx
>> > > default:group::rwx
>> > > default:other::---
>> > >
>> > > ls -latrh /pictures
>> > > total 4.0K
>> > > dr-xr-xr-x. 22 root  root  4.0K Nov  6 12:41 ..
>> > > drwxrws---+  2 nfs01 nfs01   21 Nov  6 13:10 Testing
>> > > -rw-rw-r--   1 nfs01 nfs010 Nov  6 13:44 test.txt
>> > > drwxrws---+  3 nfs01 nfs01   35 Nov  6 13:44 .
>> > >
>> > > Cheers
>> > > Bill Maidment
>> > >
>> >
>> >
>>
>>

Re: ACL Problem in SL7.2

2016-11-08 Thread Karel Lang AFD 

Hi Bill,

problem indeed.
Just suggestion/question - the NFS client running on SL 6.x is 
configured to use also NFSv4 protocol? Eg.


mount -t nfs -o vers=4 server:/data /tmp

btw i think Red Hat been solving something similar here:

'NFS client using NFSv4 ACLs loses the correct mask of a newly created 
file in subdirectories'


https://access.redhat.com/solutions/447803

unfortunately 'subscriber content' which i'm not, maybe you? :-)


On 11/08/2016 06:19 AM, Bill Maidment wrote:

Hi again
My research has revealed that nfs in SL 7.2 is translating the POSIX ACL to 
NFSv4 ACL (a completely different format).
vi appears to recognise NFSv4 ACL, but Nautilus, ls and probably other 
programs, only seem to recognise POSIX ACL.

So I have the following alternatives:
1. Stop nfs translating to NFSv4 ACL
2. Change the guest mount to translate NFSv4 ACL back to POSIX ACL
3. Change Nautilus, etc to recognise NFSv4 ACL
4. Use Samba instead of nfs

I'm not sure if 1. or 2. are possible and 3. may happen one day. Does anyone 
know of a practical solution/workaround?
Cheers
Bill

-Original message-

From:Bill Maidment 
Sent: Sunday 6th November 2016 19:56
To: Karel Lang AFD ; SCIENTIFIC-LINUX-USERS@FNAL.GOV
Subject: RE: ACL Problem in SL7.2

Thanks for the response Karel.
umask is the standard 0022 and this is a top level directory on the host 
machine.
I am using SL 6.8 to access the directory via nfs share.
It looks like there is no problem if the file is created with vi
But if I use Nautilus then that's when I get the issue.
So Nautilus on SL 6.8 seems to be the culprit (or is it caused by nfs?)
Cheers
Bill

-Original message-

From:Karel Lang AFD 
Sent: Sunday 6th November 2016 16:16
To: Bill Maidment ; SCIENTIFIC-LINUX-USERS@FNAL.GOV
Subject: Re: ACL Problem in SL7.2

Hi Bill
just pasted your work here to CLI and works OK on SL 6.7 and SL 7.2 here...
It has to be something else .. umask? or inherited from directory higher up?
Maybe strace would help to see whats happening exactly?

cheers

On 11/06/2016 03:58 AM, Bill Maidment wrote:

Hi
I am trying to set up ACL on a directory such that any new file created in the 
directory has permissions of 0660.
However, when I create a new file, the permissions are set as 0664 (see 
test.txt file below)
Is this a bug or am I doing something wrong?

These are the commands I used:

chmod -R u+rwX,g+rwXs,o-rwx /pictures

setfacl -d -m u::rwx,g::rwx,o::--- /pictures

getfacl /pictures
getfacl: Removing leading '/' from absolute path names
# file: pictures
# owner: nfs01
# group: nfs01
# flags: -s-
user::rwx
group::rwx
other::---
default:user::rwx
default:group::rwx
default:other::---

ls -latrh /pictures
total 4.0K
dr-xr-xr-x. 22 root  root  4.0K Nov  6 12:41 ..
drwxrws---+  2 nfs01 nfs01   21 Nov  6 13:10 Testing
-rw-rw-r--   1 nfs01 nfs010 Nov  6 13:44 test.txt
drwxrws---+  3 nfs01 nfs01   35 Nov  6 13:44 .

Cheers
Bill Maidment











--
*Karel Lang*
*Unix/Linux Administration*
l...@afd.cz | +420 731 13 40 40
AUFEER DESIGN, s.r.o. | www.aufeerdesign.cz

devtoolset-4 eclipse dies on an up to date sl7 machine

2016-11-08 Thread Niels Walet 
When I type
scl enable devtoolset-4 eclipse, (and I have cleaned out the .eclipse directory 
beforehand, as well as uninstalled and reinstalled devtoolset-4), I see the 
errors below in the log file. Searching on the internet, it suggests an 
inconsistency between the compilation of packages inside eclipse. Anyone else 
seen these messages? The C++ debugger runs fine...

It looks like eclipse is looking for an older version of emf-core (2.90): 
Installed version is
devtoolset-4-eclipse-emf-core.x86_641:2.11.0-4.2.el7 @sl-softwarecollections
devtoolset-4-eclipse-emf-runtime.noarch 2.11.0-4.2.el7   @sl-softwarecollections

Is there an easy way to resolve this?


A small selection of the key error messages:

  Unresolved requirement: Require-Bundle: org.eclipse.ui; 
bundle-version="[3.5.0,4.0.0)"
 Unresolved requirement: Require-Bundle: org.eclipse.ui.workbench; 
bundle-version="[3.105.0,4.0.0)"; visibility:="reexport"
Unresolved requirement: Import-Package: 
org.eclipse.e4.ui.internal.workbench
   Unresolved requirement: Require-Bundle: 
org.eclipse.e4.ui.model.workbench; bundle-version="1.0.0"
  Unresolved requirement: Require-Bundle: 
org.eclipse.emf.ecore; bundle-version="2.9.0"
  Unresolved requirement: Require-Bundle: org.eclipse.ui; 
bundle-version="[3.5.0,4.0.0)"
 Unresolved requirement: Require-Bundle: org.eclipse.ui.workbench; 
bundle-version="[3.105.0,4.0.0)"; visibility:="reexport"
Unresolved requirement: Import-Package: 
org.eclipse.e4.ui.internal.workbench
   Unresolved requirement: Require-Bundle: 
org.eclipse.e4.ui.model.workbench; bundle-version="1.0.0"
  Unresolved requirement: Require-Bundle: 
org.eclipse.emf.ecore; bundle-version="2.9.0"


---
Prof. Niels R. Walet Phone:  +44(0)1613063693
School of Physics and Astronomy Mobile: +44(0)7516622121
The University of ManchesterRoom 7.7, Schuster Building
Manchester, M13 9PL,  UK
email: niels.wa...@manchester.ac.uk   twitter: @nwalet

RE: ACL Problem in SL7.2

2016-11-08 Thread Andrew C Aitchison 

On Tue, 8 Nov 2016, Bill Maidment wrote:


Hi again
My research has revealed that nfs in SL 7.2 is translating the
POSIX ACL to NFSv4 ACL (a completely different format).


I wondered if that was the problem. Sun was working hard to be compatible 
with Microsoft when the NFSv4 ACL spec was written.



vi appears to recognise NFSv4 ACL, but Nautilus, ls and probably other 
programs, only seem to recognise POSIX ACL.

So I have the following alternatives:
1. Stop nfs translating to NFSv4 ACL
2. Change the guest mount to translate NFSv4 ACL back to POSIX ACL
3. Change Nautilus, etc to recognise NFSv4 ACL
4. Use Samba instead of nfs

I'm not sure if 1. or 2. are possible and 3. may happen one day.
Does anyone know of a practical solution/workaround?


Since NFS ACLs are Microsoft-like, Samba may not solve the issue -
https://wiki.samba.org/index.php/Shares_with_POSIX_ACLs#File_system_ACLs
does not appear to mention setfacl or getfacl ...

Do you need to use ACLs, or can you get by with unix user/group/other ?

You may get more reliable behaviour if you work on a directory nearer the 
branches. Permissions on the mount-point directory are often "interesting" 
edge cases and often different between client and server and can change 
when the remote tree is mounted or unmounted. An automounter will add an 
extra layer of complication.



Cheers
Bill

-Original message-

From:Bill Maidment 
Sent: Sunday 6th November 2016 19:56
To: Karel Lang AFD ; SCIENTIFIC-LINUX-USERS@FNAL.GOV
Subject: RE: ACL Problem in SL7.2

Thanks for the response Karel.
umask is the standard 0022 and this is a top level directory on the host 
machine.
I am using SL 6.8 to access the directory via nfs share.
It looks like there is no problem if the file is created with vi
But if I use Nautilus then that's when I get the issue.
So Nautilus on SL 6.8 seems to be the culprit (or is it caused by nfs?)
Cheers
Bill

-Original message-

From:Karel Lang AFD 
Sent: Sunday 6th November 2016 16:16
To: Bill Maidment ; SCIENTIFIC-LINUX-USERS@FNAL.GOV
Subject: Re: ACL Problem in SL7.2

Hi Bill
just pasted your work here to CLI and works OK on SL 6.7 and SL 7.2 here...
It has to be something else .. umask? or inherited from directory higher up?
Maybe strace would help to see whats happening exactly?

cheers

On 11/06/2016 03:58 AM, Bill Maidment wrote:

Hi
I am trying to set up ACL on a directory such that any new file created in the 
directory has permissions of 0660.
However, when I create a new file, the permissions are set as 0664 (see 
test.txt file below)
Is this a bug or am I doing something wrong?

These are the commands I used:

chmod -R u+rwX,g+rwXs,o-rwx /pictures

setfacl -d -m u::rwx,g::rwx,o::--- /pictures

getfacl /pictures
getfacl: Removing leading '/' from absolute path names
# file: pictures
# owner: nfs01
# group: nfs01
# flags: -s-
user::rwx
group::rwx
other::---
default:user::rwx
default:group::rwx
default:other::---

ls -latrh /pictures
total 4.0K
dr-xr-xr-x. 22 root  root  4.0K Nov  6 12:41 ..
drwxrws---+  2 nfs01 nfs01   21 Nov  6 13:10 Testing
-rw-rw-r--   1 nfs01 nfs010 Nov  6 13:44 test.txt
drwxrws---+  3 nfs01 nfs01   35 Nov  6 13:44 .

Cheers
Bill Maidment