Re: change in OS defaults (was: bug in [ -f file ] test)

� wrote: Yes, the can be overridden in /etc/sysctl.d. But I am going to modify the troublesome scripts in the $50k software and leave the security of the OS intact. Thanks. Actually, setting them to "1", is not "leaving the OS security intact" -- it's adding new, non-default security

Re: bug in [ -f file ] test

On Thu, Jul 28, 2016 at 2:49 PM, László Házy wrote: > [root]# cat /usr/lib/sysctl.d/50-default.conf | grep fs > fs.protected_hardlinks = 1 > fs.protected_symlinks = 1 > ​You can change those parameters in the file. Or you can do a test by doing: sysctl -w

Re: bug in [ -f file ] test

[root]# cat /usr/lib/sysctl.d/50-default.conf | grep fs fs.protected_hardlinks = 1 fs.protected_symlinks = 1 I guess this explains it. Problem is (my problem now) that it breaks the startup scripts of a $5 software, which does work on an older FedoraCore. Is this a kernel problem then? Thanks

Re: bug in [ -f file ] test

On 7/28/16 2:19 PM, Piotr Grzybowski wrote: > > ok, so if we now have discovered that it is +t that makes the difference and > also that it is not a bash bug, I wonder what kernel version are you running? > did Chet tests include sticky bit and the same kernel? It's a more-or-less vanilla

Re: bug in [ -f file ] test

yeah, thats why I asked about version, but never mind that, Laszlo: I would like to see : cat /usr/lib/sysctl.d/50-default.conf | grep fs pg On 28 Jul 2016, at 20:56, Charles Daffern wrote: > As far as I'm aware, the inability to use symlinks owned by another user > in a sticky directory

Re: bug in [ -f file ] test

As far as I'm aware, the inability to use symlinks owned by another user in a sticky directory is a security feature of some kernels. It helps to prevent symlink attacks. signature.asc Description: OpenPGP digital signature

Re: bug in [ -f file ] test

ok, so if we now have discovered that it is +t that makes the difference and also that it is not a bash bug, I wonder what kernel version are you running? did Chet tests include sticky bit and the same kernel? pg On 28 Jul 2016, at 19:46, László Házy wrote: > I did, and then everything

Re: bug in [ -f file ] test

On 7/28/16 12:52 PM, László Házy wrote: > Thanks for the effort Chet. Here are the results of some tests I have done, > including what you requested. Note that I have SELinux as disabled. > > [user1]# cat /var/tmp/link > cat: /var/tmp/link: Permission denied This is consistent with my results.

Re: bug in [ -f file ] test

"Greg Wooledge" <wool...@eeg.ccf.org> > > Cc: bug-bash@gnu.org > > Sent: Thursday, July 28, 2016 2:18:55 AM > > Subject: Re: bug in [ -f file ] test > > > > I had disabled SELinux, and got the same results. So it is not > > SELinux. > How did

Re: bug in [ -f file ] test

- Original Message - > From: "László Házy" <haz...@yahoo.com> > To: "Greg Wooledge" <wool...@eeg.ccf.org> > Cc: bug-bash@gnu.org > Sent: Thursday, July 28, 2016 2:18:55 AM > Subject: Re: bug in [ -f file ] test > > I had disabled SE

Re: bug in [ -f file ] test

On 7/27/16 3:34 PM, László Házy wrote: > You have probably not done the first command: "[user1]$ chmod g+rx > /home/user1". In my case, there is no access problem. I can ls and cd. > Thing is, even root gets the wrong answer if it does the "is file?" query. I performed that command, but I tore it

Re: bug in [ -f file ] test

On 7/26/16 5:07 PM, László Házy wrote: > Hmm, interesting. I can reproduce your results. Thanks. > However, note the following: > > [user1]$ chmod g+rx /home/user1 > [user1]$ touch file; ls -l file > -rw-r--r--. 1 user1 users0 Jul 26 15:24 file > > [user1]$ su user2 -c "ln -s

Re: bug in [ -f file ] test

> Am 27.07.2016 um 18:55 schrieb László Házy : > > Here it goes. Note that the second command you asked for returns the same as > the "file" entry in the first command. Thanks. Yeah, I meant: $ ls -Zd /home/user1 to show the entry of the directory itself, not its content. -

Re: bug in [ -f file ] test

Here it goes. Note that the second command you asked for returns the same as the "file" entry in the first command. Thanks. [user1]$ ls -Z /home/user1 unconfined_u:object_r:user_home_t:s0 Desktop unconfined_u:object_r:user_home_t:s0 Documents unconfined_u:object_r:user_home_t:s0 Downloads

Re: bug in [ -f file ] test

> Am 27.07.2016 um 18:13 schrieb László Házy : > > Yes, SELinux is active. Fine. Can you please provide: $ ls -Z /home/user1 $ ls -Z /home/user1/file -- Reuti > On Wed, 2016-07-27 at 17:55 +0200, Reuti wrote: >>> >>> Am 27.07.2016 um 17:36 schrieb László Házy < >>>

Re: bug in [ -f file ] test

> Am 27.07.2016 um 17:36 schrieb László Házy : > > Yes, user2 has rx access to /home/user1. This is done by the first command in > the list of commands, namely: "[user1]$ chmod g+rx /home/user1". The two > users are part of the same group. > > An even more troublesome

Re: bug in [ -f file ] test

Yes, user2 has rx access to /home/user1. This is done by the first command in the list of commands, namely: "[user1]$ chmod g+rx /home/user1". The two users are part of the same group. An even more troublesome variation, involving root, is the following: [user1]$ touch file; ls -l file -rw-r--r--.

Re: bug in [ -f file ] test

Am 26.07.2016 um 23:07 schrieb László Házy: > Hmm, interesting. I can reproduce your results. Thanks. > However, note the following: > > [user1]$ chmod g+rx /home/user1 > [user1]$ touch file; ls -l file > -rw-r--r--. 1 user1 users0 Jul 26 15:24 file > > [user1]$ su user2 -c "ln -s

Re: bug in [ -f file ] test

Hmm, interesting. I can reproduce your results. Thanks. However, note the following: [user1]$ chmod g+rx /home/user1 [user1]$ touch file; ls -l file -rw-r--r--. 1 user1 users0 Jul 26 15:24 file [user1]$ su user2 -c "ln -s /home/user1/file /var/tmp/link" [user1]$ ls -l /var/tmp/link lrwxrwxrwx.

Re: bug in [ -f file ] test

Are you sure "file" is a link to an actual file, not, say, a directory? $ rpm -q bash; echo $BASH_VERSION; cat /etc/redhat-release bash-4.3.42-3.fc23.x86_64 4.3.42(1)-release Fedora release 23 (Twenty Three) $ touch file; ln -s file link; [[ -f link ]]; echo $? 0 On Tue, Jul 26, 2016 at 12:58