On Thu, Sep 1, 2016 at 5:30 PM, centos-request@centos.org wrote:
Send CentOS mailing list submissions to centos@centos.org
To subscribe or unsubscribe via the World Wide Web, visit https://lists.centos.org/mailman/listinfo/centos or, via email, send a message with subject or body 'help' to centos-request@centos.org
You can reach the person managing the list at centos-owner@centos.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of CentOS digest..."
Today's Topics:
- Re: CentOS 6 - logwatch report not in HTML format (Arun Khan)
- Re: NODEJS010-NPM is not getting installed due to dependency errors on Custom Centos ISO installation (Jim Perrin)
- Re: CentOS 6 - logwatch report not in HTML format (Alexander Farber)
- Re: CentOS 6 - logwatch report not in HTML format (Arun Khan)
- Re: CentOS 6 - logwatch report not in HTML format (Alexander Farber)
- Re: group write permissions not being respected (Gordon Messmer)
- Re: CentOS 6 - logwatch report not in HTML format (Arun Khan)
- Re: group write permissions not being respected (Pat Haley)
- Re: group write permissions not being respected (m.roth@5-cent.us)
- Re: group write permissions not being respected (Pat Haley)
- Re: group write permissions not being respected (Chris Murphy)
- Perl Unsafe Module Path Handling Directory Traversal Vulnerability ( CVE-2016-1238) (Sidharth Sharma)
- Bind Vulnerability CVE-2016-2775 (Sidharth Sharma)
- Re: "Windows" share issue; access via smb:// fails, "mount -t cifs" works (Toralf Lund)
- Re: Bind Vulnerability CVE-2016-2775 (James Pearson)
- Re: Bind Vulnerability CVE-2016-2775 (Mike Burger)
Message: 1 Date: Wed, 31 Aug 2016 07:11:11 -0700 From: Arun Khan knura9@gmail.com To: CentOS mailing list centos@centos.org Subject: Re: [CentOS] CentOS 6 - logwatch report not in HTML format Message-ID: CAHhM8gCz6SDqu8i5aHkUU58Sb91cHdNKUy=J_rYP25X48gk22Q@mail.gmail.com Content-Type: text/plain; charset=UTF-8
On Mon, Aug 29, 2016 at 10:24 PM, Alexander Farber alexander.farber@gmail.com wrote:
No, I mean there is sometimes a variable for mail format too:
The HTML formatting is a logwatch option, invoked through the logwatch.conf file.
-- Arun Khan
Message: 2 Date: Wed, 31 Aug 2016 09:20:26 -0500 From: Jim Perrin jperrin@centos.org To: centos@centos.org Subject: Re: [CentOS] NODEJS010-NPM is not getting installed due to dependency errors on Custom Centos ISO installation Message-ID: a607d751-c5e7-91eb-9e81-b6cdb379ecfa@centos.org Content-Type: text/plain; charset=windows-1252
On 08/31/2016 03:48 AM, SUDHANSHU BHUTANI wrote:
Hi,
I have built successfully all the dependent packages of nodejs010 and npm.
I have used following command:- *rpmbuild --define 'scl nodejs010' --bb SPEC/name_of_spec.spec*
You should really use mock, so that you don't have unintended libraries from your build host included/linked/required in the resulting rpm.
Thanks Jim for responding.
I tried with mock configuration, but, not sure, i am still getting the same errors via repoclosre tool:- This directory has got all the RPMs formed by mock.
[root@localhost YUM_CISCO_RPMS]# repoclosure -r Cisco-yum-dep-check Reading in repository metadata - please wait.... Checking Dependencies Repos looked at: 1 Cisco-yum-dep-check Num Packages in Repos: 1515 package: nodejs010-nodejs-are-we-there-yet-1.0.4-1.el7.centos.noarch from Cisco-yum-dep-check unresolved deps: nodejs010-npm(readable-stream) < 0:2 package: nodejs010-nodejs-cmd-shim-2.0.0-2.el7.centos.noarch from Cisco-yum-dep-check unresolved deps: nodejs010-npm(graceful-fs) < 0:4 package: nodejs010-nodejs-columnify-1.3.2-3.el7.centos.noarch from Cisco-yum-dep-check unresolved deps: nodejs010-npm(strip-ansi) >= 0:2.0.0 package: nodejs010-nodejs-fstream-ignore-1.0.2-1.el7.centos.noarch from Cisco-yum-dep-check unresolved deps: nodejs010-npm(minimatch) < 0:3 package: nodejs010-nodejs-gauge-1.2.2-3.el7.centos.noarch from Cisco-yum-dep-check unresolved deps: nodejs010-npm(has-unicode) < 0:2 package: nodejs010-nodejs-init-package-json-1.9.1-1.el7.centos.noarch from Cisco-yum-dep-check unresolved deps: nodejs010-npm(promzard) >= 0:0.3.0 package: nodejs010-nodejs-npm-registry-client-7.0.8-1.el7.centos.noarch from Cisco-yum-dep-check unresolved deps: nodejs010-npm(retry) >= 0:0.8.0 nodejs010-npm(request) >= 0:2.47.0 nodejs010-npm(concat-stream) >= 0:1.4.6 package: nodejs010-nodejs-which-1.2.0-1.el7.centos.noarch from Cisco-yum-dep-check unresolved deps: nodejs010-npm(is-absolute) < 0:0.2
The only difference from my (for build of nodejs010-nodejs-which-1.2.0-1.el7.centos.noarch.rpm) build-log and http://cbs.centos.org/kojifiles/packages/nodejs010-nodejs-are-we-there-yet/1...
is following line:- *Requires: nodejs010-nodejs(engine) nodejs010-npm(delegates) nodejs010-npm(readable-stream)* - >> THIS IS FROM CBS mock log
and following is my build log:- *Requires: nodejs010-nodejs(engine) nodejs010-npm(delegates) >= 0.1.0 nodejs010-npm(delegates) < 0.2 nodejs010-npm(readable-stream) >= 1.1.13 nodejs010-npm(readable-stream) < 2*
I am not sure, why parsing of these version is defining a range, maybe its coming from package.json file. I feel, its related to nodejs010-build package which has root/usr/lib/rpm/nodejs010.req, i defined mock configuration like this:- config_opts['root'] = 'epel-7-x86_64' config_opts['target_arch'] = 'x86_64' config_opts['legal_host_arches'] = ('x86_64',) config_opts['chroot_setup_cmd'] = 'install @buildsys-build scl-utils-build nodejs010-build'
Do they look good?
Following is my build.log [sbhutani@localhost ~]$ cat nodejs-build/nodejs010- Display all 316 possibilities? (y or n) [sbhutani@localhost ~]$ cat nodejs-build/nodejs010-nodejs-are-we-there-yet-1.0.4-1.el7.src.rpm/build.log Mock Version: 1.2.18 ENTER ['do'](['bash', '--login', '-c', '/usr/bin/rpmbuild -bs --target x86_64 --nodeps /builddir/build/SPECS/nodejs-are-we-there-yet.spec'], chrootPath='/var/lib/mock/epel-7-x86_64/root'shell=FalseprintOutput=Falseenv={'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOSTNAME': 'mock', 'PROMPT_COMMAND': 'printf "\033]0;<mock-chroot>\007"', 'HOME': '/builddir', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'PS1': '<mock-chroot> \s-\v\$ '}gid=135user='mockbuild'timeout=0logger=<mockbuild.trace_decorator.getLog object at 0x22e3390>uid=1000) Executing command: ['bash', '--login', '-c', '/usr/bin/rpmbuild -bs --target x86_64 --nodeps /builddir/build/SPECS/nodejs-are-we-there-yet.spec'] with env {'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOSTNAME': 'mock', 'PROMPT_COMMAND': 'printf "\033]0;<mock-chroot>\007"', 'HOME': '/builddir', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'PS1': '<mock-chroot> \s-\v\$ '} and shell False Building target platforms: x86_64 Building for target x86_64 Wrote: /builddir/build/SRPMS/nodejs-are-we-there-yet-1.0.4-1.el7.centos.src.rpm Child return code was: 0 Mock Version: 1.2.18 ENTER ['do'](['bash', '--login', '-c', '/usr/bin/rpmbuild -bs --target x86_64 --nodeps /builddir/build/SPECS/nodejs-are-we-there-yet.spec'], chrootPath='/var/lib/mock/epel-7-x86_64/root'shell=FalseprintOutput=Trueenv={'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOSTNAME': 'mock', 'PROMPT_COMMAND': 'printf "\033]0;<mock-chroot>\007"', 'HOME': '/builddir', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'PS1': '<mock-chroot> \s-\v\$ '}gid=135user='mockbuild'timeout=0logger=<mockbuild.trace_decorator.getLog object at 0x1772390>uid=1000) Executing command: ['bash', '--login', '-c', '/usr/bin/rpmbuild -bs --target x86_64 --nodeps /builddir/build/SPECS/nodejs-are-we-there-yet.spec'] with env {'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOSTNAME': 'mock', 'PROMPT_COMMAND': 'printf "\033]0;<mock-chroot>\007"', 'HOME': '/builddir', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'PS1': '<mock-chroot> \s-\v\$ '} and shell False Building target platforms: x86_64 Building for target x86_64 Wrote: /builddir/build/SRPMS/nodejs010-nodejs-are-we-there-yet-1.0.4-1.el7.centos.src.rpm Child return code was: 0 Mock Version: 1.2.18 ENTER ['do'](['bash', '--login', '-c', '/usr/bin/rpmbuild -bs --target x86_64 --nodeps /builddir/build/SPECS/nodejs-are-we-there-yet.spec'], chrootPath='/var/lib/mock/epel-7-x86_64/root'shell=FalseprintOutput=Falseenv={'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOSTNAME': 'mock', 'PROMPT_COMMAND': 'printf "\033]0;<mock-chroot>\007"', 'HOME': '/builddir', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'PS1': '<mock-chroot> \s-\v\$ '}gid=135user='mockbuild'timeout=0logger=<mockbuild.trace_decorator.getLog object at 0x142d390>uid=1000) Executing command: ['bash', '--login', '-c', '/usr/bin/rpmbuild -bs --target x86_64 --nodeps /builddir/build/SPECS/nodejs-are-we-there-yet.spec'] with env {'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOSTNAME': 'mock', 'PROMPT_COMMAND': 'printf "\033]0;<mock-chroot>\007"', 'HOME': '/builddir', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'PS1': '<mock-chroot> \s-\v\$ '} and shell False Building target platforms: x86_64 Building for target x86_64 Wrote: /builddir/build/SRPMS/nodejs010-nodejs-are-we-there-yet-1.0.4-1.el7.centos.src.rpm Child return code was: 0 ENTER ['do'](['bash', '--login', '-c', u'/usr/bin/rpmbuild -bb --target x86_64 --nodeps /builddir/build/SPECS/nodejs-are-we-there-yet.spec'], chrootPath='/var/lib/mock/epel-7-x86_64/root'shell=Falseuid=1000env={'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOSTNAME': 'mock', 'PROMPT_COMMAND': 'printf "\033]0;<mock-chroot>\007"', 'HOME': '/builddir', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'PS1': '<mock-chroot> \s-\v\$ '}gid=135user='mockbuild'timeout=0private_network=Truelogger=<mockbuild.trace_decorator.getLog object at 0x142d390>printOutput=False) Executing command: ['bash', '--login', '-c', u'/usr/bin/rpmbuild -bb --target x86_64 --nodeps /builddir/build/SPECS/nodejs-are-we-there-yet.spec'] with env {'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOSTNAME': 'mock', 'PROMPT_COMMAND': 'printf "\033]0;<mock-chroot>\007"', 'HOME': '/builddir', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'PS1': '<mock-chroot> \s-\v\$ '} and shell False Building target platforms: x86_64 Building for target x86_64 Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.cNqdgI + umask 022 + cd /builddir/build/BUILD + cd /builddir/build/BUILD + rm -rf package + /usr/bin/gzip -dc /builddir/build/SOURCES/are-we-there-yet-1.0.4.tgz + /usr/bin/tar -xf - + STATUS=0 + '[' 0 -ne 0 ']' + cd package + /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w . + rm -rf node_modules + exit 0 Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.iiP8RP + umask 022 + cd /builddir/build/BUILD + cd package + exit 0 Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.IFmFuX + umask 022 + cd /builddir/build/BUILD + '[' /builddir/build/BUILDROOT/nodejs010-nodejs-are-we-there-yet-1.0.4-1.el7.centos.x86_64 '!=' / ']' + rm -rf /builddir/build/BUILDROOT/nodejs010-nodejs-are-we-there-yet-1.0.4-1.el7.centos.x86_64 ++ dirname /builddir/build/BUILDROOT/nodejs010-nodejs-are-we-there-yet-1.0.4-1.el7.centos.x86_64 + mkdir -p /builddir/build/BUILDROOT + mkdir /builddir/build/BUILDROOT/nodejs010-nodejs-are-we-there-yet-1.0.4-1.el7.centos.x86_64 + cd package + mkdir -p /builddir/build/BUILDROOT/nodejs010-nodejs-are-we-there-yet-1.0.4-1.el7.centos.x86_64/opt/rh/nodejs010/root/usr/lib/node_modules/are-we-there-yet + cp -pr package.json index.js /builddir/build/BUILDROOT/nodejs010-nodejs-are-we-there-yet-1.0.4-1.el7.centos.x86_64/opt/rh/nodejs010/root/usr/lib/node_modules/are-we-there-yet + /usr/lib/rpm/nodejs010-symlink-deps /opt/rh/nodejs010/root/usr/lib/node_modules + /usr/lib/rpm/find-debuginfo.sh --strict-build-id -m --run-dwz --dwz-low-mem-die-limit 10000000 --dwz-max-die-limit 110000000 /builddir/build/BUILD/package /usr/lib/rpm/sepdebugcrcfix: Updated 0 CRC32s, 0 CRC32s did match. + /usr/lib/rpm/check-buildroot + /usr/lib/rpm/brp-scl-compress /opt/rh/nodejs010/root + /usr/lib/rpm/brp-strip-static-archive /usr/bin/strip + /usr/lib/rpm/brp-scl-python-bytecompile /usr/bin/python 1 /opt/rh/nodejs010/root + /usr/lib/rpm/brp-python-hardlink + /usr/lib/rpm/redhat/brp-java-repack-jars Processing files: nodejs010-nodejs-are-we-there-yet-1.0.4-1.el7.centos.noarch Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.7DYIy5 + umask 022 + cd /builddir/build/BUILD + cd package + DOCDIR=/builddir/build/BUILDROOT/nodejs010-nodejs-are-we-there-yet-1.0.4-1.el7.centos.x86_64/opt/rh/nodejs010/root/usr/share/doc/nodejs010-nodejs-are-we-there-yet-1.0.4 + export DOCDIR + /usr/bin/mkdir -p /builddir/build/BUILDROOT/nodejs010-nodejs-are-we-there-yet-1.0.4-1.el7.centos.x86_64/opt/rh/nodejs010/root/usr/share/doc/nodejs010-nodejs-are-we-there-yet-1.0.4 + cp -pr README.md /builddir/build/BUILDROOT/nodejs010-nodejs-are-we-there-yet-1.0.4-1.el7.centos.x86_64/opt/rh/nodejs010/root/usr/share/doc/nodejs010-nodejs-are-we-there-yet-1.0.4 + exit 0 Finding Provides: /usr/lib/rpm/nodejs010.prov Finding Requires(interp): Finding Requires(rpmlib): Finding Requires(verify): Finding Requires(pre): Finding Requires(post): Finding Requires(preun): Finding Requires(postun): Finding Requires(pretrans): Finding Requires(posttrans): Finding Requires: /usr/lib/rpm/nodejs010.req Provides: nodejs010-nodejs-are-we-there-yet = 1.0.4-1.el7.centos nodejs010-npm(are-we-there-yet) = 1.0.4 Requires(rpmlib): rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 Requires: nodejs010-nodejs(engine) nodejs010-npm(delegates) >= 0.1.0 nodejs010-npm(delegates) < 0.2 nodejs010-npm(readable-stream) >= 1.1.13 nodejs010-npm(readable-stream) < 2 Checking for unpackaged file(s): /usr/lib/rpm/check-files /builddir/build/BUILDROOT/nodejs010-nodejs-are-we-there-yet-1.0.4-1.el7.centos.x86_64 Wrote: /builddir/build/RPMS/nodejs010-nodejs-are-we-there-yet-1.0.4-1.el7.centos.noarch.rpm Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.yi6hbn + umask 022 + cd /builddir/build/BUILD + cd package + /usr/bin/rm -rf /builddir/build/BUILDROOT/nodejs010-nodejs-are-we-there-yet-1.0.4-1.el7.centos.x86_64 + exit 0 Child return code was: 0 [sbhutani@localhost ~]$
Can any one catch difference between my build.log and CBS build.log. If hhorak is on this mailing list who actually built this package on CBS, can help? Appreciate your inputs.
Following is the list of RPMs cloned and built from GIT:-
<snip>
*However, when we copy these RPMS to our ISO, anaconda installer fails to install due to dependency errors:-*
You should use the 'repoclosure' utility to make sure that you have met all the dependencies of packages in the repo on your iso.
How is it possible, to get these errors, how come packages are not satisfying minimum dependency for working of NPM?
repoclosure should tell you. You may be missing something scl related.
If i do yumdownloader for all these above RPMs from repo: [centos-sclo-rh] : http://mirror.centos.org/centos/7/sclo/x86_64/rh/nodejs010/), then i get following RPMs without "centos" name:-
Correct. This is an rpm macro change. by default the 'centos' is added in there.
*If i copy paste above RPMS to my custom ISO, then anaconda successfully installs these packages, without any errors*
This would suggest something is wrong with your build. See previous statement about using mock vs rpmbuild.
*What is there is these already built RPMs (taken from repo: [centos-sclo-rh] : http://mirror.centos.org/centos/7/sclo/x86_64/rh/nodejs010/) which is not there in my built RPMS?*
That's kind of up to you to figure out, since we can't see your custom built ones.
Any pointers for this, as we feel, there is some inconsistency in the version available on git.centos.org/git/rpms/<name_of_pkg>.git ?
More likely it's in your build method.
-- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77
Message: 3 Date: Wed, 31 Aug 2016 16:58:17 +0200 From: Alexander Farber alexander.farber@gmail.com To: CentOS mailing list centos@centos.org Subject: Re: [CentOS] CentOS 6 - logwatch report not in HTML format Message-ID: CAADeyWiMVpHh=CDZ6zi_OEq+5HwysoqTAOABDnM4mkYeFDhxYA@mail.gmail.com Content-Type: text/plain; charset=UTF-8
logwatch is run as cronjob.
On Wed, Aug 31, 2016 at 4:11 PM, Arun Khan knura9@gmail.com wrote:
On Mon, Aug 29, 2016 at 10:24 PM, Alexander Farber alexander.farber@gmail.com wrote:
No, I mean there is sometimes a variable for mail format too:
The HTML formatting is a logwatch option, invoked through the logwatch.conf file.
-- Arun Khan _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Message: 4 Date: Wed, 31 Aug 2016 08:31:28 -0700 From: Arun Khan knura9@gmail.com To: CentOS mailing list centos@centos.org Subject: Re: [CentOS] CentOS 6 - logwatch report not in HTML format Message-ID: CAHhM8gDhhgRNb1C2rKRdE+v8w_fEhBmCvarf3MxO=njxL7w3-g@mail.gmail.com Content-Type: text/plain; charset=UTF-8
On Wed, Aug 31, 2016 at 7:58 AM, Alexander Farber alexander.farber@gmail.com wrote:
logwatch is run as cronjob.
Let's take cron out of the picture. Invoking logwatch from an interactive shell -- no joy. The report still goes out in text format.
-- Arun Khan
Message: 5 Date: Wed, 31 Aug 2016 17:59:44 +0200 From: Alexander Farber alexander.farber@gmail.com To: CentOS mailing list centos@centos.org Subject: Re: [CentOS] CentOS 6 - logwatch report not in HTML format Message-ID: CAADeyWiYQ_TNjZHZ9af2x3TM_Lq+U9LE+y4aheb6BXV_TBwGaQ@mail.gmail.com Content-Type: text/plain; charset=UTF-8
You should have provided more info initially.
"goes out in text format" might mean several things.
On Wed, Aug 31, 2016 at 5:31 PM, Arun Khan knura9@gmail.com wrote:
On Wed, Aug 31, 2016 at 7:58 AM, Alexander Farber alexander.farber@gmail.com wrote:
logwatch is run as cronjob.
Let's take cron out of the picture. Invoking logwatch from an interactive shell -- no joy. The report still goes out in text format.
-- Arun Khan _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Message: 6 Date: Wed, 31 Aug 2016 09:50:45 -0700 From: Gordon Messmer gordon.messmer@gmail.com To: CentOS mailing list centos@centos.org Subject: Re: [CentOS] group write permissions not being respected Message-ID: 8d10f9b1-0ed9-0217-ae0e-726acd1d9a87@gmail.com Content-Type: text/plain; charset=windows-1252; format=flowed
On 08/30/2016 03:01 PM, Pat Haley wrote:
the owner of a directory can still write to that directory but any other member of the associated group cannot, even though the directory clearly has group write permissions set
Use "getfacl" on both the client and server side to view the complete permission set. What do those look like?
Message: 7 Date: Wed, 31 Aug 2016 10:00:42 -0700 From: Arun Khan knura9@gmail.com To: CentOS mailing list centos@centos.org Subject: Re: [CentOS] CentOS 6 - logwatch report not in HTML format Message-ID: CAHhM8gBBc+i9VH=eiGM+K7ePerQbv4Nraa5ck7YMEixrhbzaoQ@mail.gmail.com Content-Type: text/plain; charset=UTF-8
On Wed, Aug 31, 2016 at 8:59 AM, Alexander Farber alexander.farber@gmail.com wrote:
You should have provided more info initially.
"goes out in text format" might mean several things.
I don't know what you mean by "several things"
In the context of logwatch the only options are HTML or TEXT. Please see my OP.
Thanks for your assistance.
-- Arun Khan
Message: 8 Date: Wed, 31 Aug 2016 13:11:09 -0400 From: Pat Haley phaley@mit.edu To: centos@centos.org Cc: Steve Postma SPostma@ztechnet.com Subject: Re: [CentOS] group write permissions not being respected Message-ID: 8d59038f-3dbe-5bff-9673-fbada1d3f31c@mit.edu Content-Type: text/plain; charset=windows-1252; format=flowed
So far, those look the same
client:
[root@mseas FixOwn]# getfacl /gdata/bibliography/Work/GroupBib/trunk/ getfacl: Removing leading '/' from absolute path names # file: gdata/bibliography/Work/GroupBib/trunk/ # owner: phaley # group: mseasweb # flags: -s- user::rwx group::rwx other::r-x
server:
[root@mseas-data2 ~]# getfacl /gdata/bibliography/Work/GroupBib/trunk/ getfacl: Removing leading '/' from absolute path names # file: gdata/bibliography/Work/GroupBib/trunk/ # owner: phaley # group: mseasweb # flags: -s- user::rwx group::rwx other::r-x
On 08/31/2016 12:50 PM, Gordon Messmer wrote:
On 08/30/2016 03:01 PM, Pat Haley wrote:
the owner of a directory can still write to that directory but any other member of the associated group cannot, even though the directory clearly has group write permissions set
Use "getfacl" on both the client and server side to view the complete permission set. What do those look like?
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Pat Haley Email: phaley@mit.edu Center for Ocean Engineering Phone: (617) 253-6824 Dept. of Mechanical Engineering Fax: (617) 253-8125 MIT, Room 5-213 http://web.mit.edu/phaley/www/ 77 Massachusetts Avenue Cambridge, MA 02139-4301
Message: 9 Date: Wed, 31 Aug 2016 14:04:28 -0400 From: m.roth@5-cent.us To: "CentOS mailing list" centos@centos.org Subject: Re: [CentOS] group write permissions not being respected Message-ID: b9abfd5a5a37f29bff085aae6174877f.squirrel@host290.hostmonster.com Content-Type: text/plain;charset=utf-8
Stupid question, and note I missed most of the earlier posts in this thread: what are the permissions on the directory that this directory are in?
mark
Message: 10 Date: Wed, 31 Aug 2016 15:06:25 -0400 From: Pat Haley phaley@mit.edu To: centos@centos.org Subject: Re: [CentOS] group write permissions not being respected Message-ID: d9ac7e12-3283-ea9e-a5b0-5dcd8d27d87d@mit.edu Content-Type: text/plain; charset=windows-1252; format=flowed
For example the directory /gdata/bibliography/Work/GroupBib/trunk/ can be written in by user phaley but not by other users who are member of the group mseasweb. The directory has permissions
[root@mseas ~]# ls -lh /gdata/bibliography/Work/GroupBib total 12K drwxrwsr-x 4 phaley mseasweb 4.0K Aug 30 12:31 trunk
The parent directory (/gdata/bibliography/Work/GroupBib) has permissions
[root@mseas ~]# ls -lh /gdata/bibliography/Work/ total 8.0K drwxrwsr-x 6 phaley mseasweb 4.0K Aug 30 14:01 GroupBib
On 08/31/2016 02:04 PM, m.roth@5-cent.us wrote:
Stupid question, and note I missed most of the earlier posts in this thread: what are the permissions on the directory that this directory are in?
mark
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Pat Haley Email: phaley@mit.edu Center for Ocean Engineering Phone: (617) 253-6824 Dept. of Mechanical Engineering Fax: (617) 253-8125 MIT, Room 5-213 http://web.mit.edu/phaley/www/ 77 Massachusetts Avenue Cambridge, MA 02139-4301
Message: 11 Date: Thu, 01 Sep 2016 03:38:11 +0000 From: Chris Murphy lists@colorremedies.com To: CentOS mailing list centos@centos.org Subject: Re: [CentOS] group write permissions not being respected Message-ID: CAJCQCtTfr6rvPGH7uMNzYE9-Q+BfZ784a5n=4S5NekA7O8VxAA@mail.gmail.com Content-Type: text/plain; charset=UTF-8
Try booting with enforcing=0 and if that fixes it, you need to find out what security label is needed for gluster.
Chances are it's easiest to use -o context= mount option on the brick, but if the brick is not exclusive to gluster you'll need chcon -R.
If that's not it, maybe try the gluster client instead of using NFS. See if you get a different result that narrows down what's going on.
My vague recollection is for Samba, without the correct SELinux label, I could neither read nor write.
Chris Murphy
Message: 12 Date: Thu, 1 Sep 2016 11:03:30 +0530 From: Sidharth Sharma sharma.sidharth86@gmail.com To: centos@centos.org Subject: [CentOS] Perl Unsafe Module Path Handling Directory Traversal Vulnerability ( CVE-2016-1238) Message-ID: CAAQ4EFk7qgWvq=ZtSOugxsgQ1S54y8cFbiG33POQme8+cDrcSw@mail.gmail.com Content-Type: text/plain; charset=UTF-8
Hello Experts,
When we can expect Security Update for Perl Vulnerability CVE-2016-1238 on CentOS 6.8 and 7.2?
-- With Thanks & Regards: Sidharth Sharma
Message: 13 Date: Thu, 1 Sep 2016 11:05:36 +0530 From: Sidharth Sharma sharma.sidharth86@gmail.com To: centos@centos.org Subject: [CentOS] Bind Vulnerability CVE-2016-2775 Message-ID: CAAQ4EF=2AeThtVjJitR3JHGhuunRJ4AZHiYDcrp4vcKFxUV=UQ@mail.gmail.com Content-Type: text/plain; charset=UTF-8
Hello Experts,
When we can expect Security Update for Bind Vulnerability on Centos 6.8/7.2? ISC BIND Lightweight Resolver Protocol Req Processing Dos Vulnerability: CVE-2016-2775
-- With Thanks & Regards: Sidharth Sharma
Message: 14 Date: Thu, 1 Sep 2016 10:26:34 +0200 From: Toralf Lund toralf.lund@pgs.com To: CentOS mailing list centos@centos.org Subject: Re: [CentOS] "Windows" share issue; access via smb:// fails, "mount -t cifs" works Message-ID: 2265d62b-32b6-6d51-5848-df84f5800723@pgs.com Content-Type: text/plain; charset="utf-8"; format=flowed
On 30/08/16 10:00, Toralf Lund wrote:
Hi,
Is anyone here using smb:// URLs to access "Windows" shares? I've been doing this for a while with common file systems at work, and it used to work just fine. Then I while back, I started getting issues; I will now just keep getting asked for a password when I try to access something through smb://. I thought at first that this meant there had been some kind of change related to permissions on the shares, but now I find that I can mount them just fine using "mount -t cifs".
I found out a bit more about this - I believe that I have the issue described here:
http://community.netapp.com/t5/Network-Storage-Protocols-Discussions/samba-3...
In other words, the problem is that "SPNEGO" fails. If I add "client use spnego = no" to /etc/samba/smb.conf, smbclient access works (I found that I also got a problem there), but unfortunately, gvfs-mount still doesn't. The debug output that I get if I run gvfsd on the command line with "GVFS_DEBUG=1" and "GVFS_SMB_DEBUG=99" actually still report SPNEGO errors, so it would appear that the smp.conf option is for some reason ignored. In other words the question may be:
How do I disabled SPNEGO for gvfs-mount?
Also, the above suggest that whether this problem occurs depends on whether "you have SMB signing turned on or not under the 'cifs' options section", but it not clear to me what options exactly this refers to. Anyone?
Oh, and some other posts I found seem to indicate that mount.cifs doesn't support SPNEGO yet, so I guess that's why a "normal" mount works.
- Toralf
In other words, I get:
gvfs-mount smb://mydomain;toralf.lund@theserver/myshare Password required for share myshare on theserver Password: Password required for share myshare on theserver Password: Password required for share myshare on theserver Password:
[ I enter the correct password, but gvs-mount keeps asking... Behaviour is the same if I try to open the URL in the file manager instead. ]
mount -t cifs -o user=toralf.lund,workgroup=mydomain //theserver/myshare /tmp_mnt/ Password:
[ At this stage the filesystem is mounted, as long as I enter the correct password. ]
Does anyone have any idea what is going on here? Why does the VFS mount fail when mount.cifs works on the same share? Is there a difference in the way authentication works, or something? Has there been a change to the smb support that might explain this?
This is on a CentOS 6 x86_64 installation with all updates applied.
- Toralf
Message: 15 Date: Thu, 1 Sep 2016 08:34:08 +0000 From: James Pearson james-p@moving-picture.com To: CentOS mailing list centos@centos.org Subject: Re: [CentOS] Bind Vulnerability CVE-2016-2775 Message-ID: 85C0B54E4752CA4F873E7C78CF0B26F5010FB3748D@LNDWSMBX01.ad.mpc.local Content-Type: text/plain; charset="us-ascii"
Sidharth Sharma:
When we can expect Security Update for Bind Vulnerability on Centos 6.8/7.2? ISC BIND Lightweight Resolver Protocol Req Processing Dos Vulnerability: CVE-2016-2775
See:
https://access.redhat.com/security/cve/cve-2016-2775
James Pearson
Message: 16 Date: Thu, 01 Sep 2016 07:45:04 -0400 From: Mike Burger mburger@bubbanfriends.org To: CentOS mailing list centos@centos.org Subject: Re: [CentOS] Bind Vulnerability CVE-2016-2775 Message-ID: 400e82588e4172b96a928e1e3aeef9e3@bubbanfriends.org Content-Type: text/plain; charset=US-ASCII; format=flowed
On 2016-09-01 4:34 am, James Pearson wrote:
Sidharth Sharma:
When we can expect Security Update for Bind Vulnerability on Centos 6.8/7.2? ISC BIND Lightweight Resolver Protocol Req Processing Dos Vulnerability: CVE-2016-2775
See:
Ouch!
Affected Packages State Platform Package State Red Hat Enterprise Linux 5 bind97 Will not fix Red Hat Enterprise Linux 6 bind Will not fix Red Hat Enterprise Linux 5 bind Will not fix Red Hat Enterprise Linux 7 bind Will not fix
-- Mike Burger http://www.bubbanfriends.org
"It's always suicide-mission this, save-the-planet that. No one ever just stops by to say 'hi' anymore." --Colonel Jack O'Neill, SG1
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
End of CentOS Digest, Vol 140, Issue 1