Re: File and directory permissions

[Dan Purgert]

 wrote:
>
> On Wed, Mar 07, 2018 at 11:54:06AM -, Dan Purgert wrote:
>
> [...]
>
>> Think of it as being somewhat like a parking lot / garage with a gate at the
>> entrance.
>
> Uh-oh. A car analogy :)
>
>> You enter the lot / garage, get your ticket, and are admitted in.  Now
>> you're free to go anywhere in the lot to find a space (equivalent of
>> opening / editing files).  
>> 
>> While you're driving around the lot, the attendant closes the gate and
>> puts up a "Lot Full" sign [...]
>
> Nice metaphor, thanks!

Once in a while, car analogies work :)


-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

Re: File and directory permissions

[Greg Wooledge]

On Wed, Mar 07, 2018 at 12:42:19PM +0100, epsilon...@tutanota.com wrote:
> OK thanks for the explanations.
> To make sure:
> 1.) To prevent this scenario, I have to do recursive chown and chmod.

No, to prevent this scenario, use the correct owner and permissions in
the first place instead of setting things up with the wrong permissions,
waiting for someone to start exploiting it, and then correcting the
permissions too late.

Assuming I understand what you mean by "this scenario".  And my
understanding is "I set up a directory with the wrong permissions,
and people did bad things there, and then I fixed the permissions,
but they continued to do bad things, but only until I rebooted."

Re: File and directory permissions

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Mar 07, 2018 at 01:11:52PM +0100, epsilon...@tutanota.com wrote:
> Tomas and Dan, thanks for the explanations. So if the process have already a 
> handle (file descriptor) to apple, it can continue using it, even when I 
> chmod 700 one of its parents. On the other hand, any new process trying to 
> get a handle to apple MUST traverse the directory tree. This is what I 
> understand. Thanks again for the explanations.

Yes, that sounds about right, perhaps with a small correction:
it doesn't have to traverse the whole path from root if it
has a handle to an intermediate directory: that's what the
system call openat() is for.

Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlqf1/8ACgkQBcgs9XrR2kZqIQCfYYuI6+7LShtFutPaatg2wd48
CioAnRU9aCHc4ZvDE9hwllp7fCeTA653
=7+m3
-END PGP SIGNATURE-

Re: File and directory permissions

[Thomas Schmitt]

Hi,

epsilon...@tutanota.com wrote:
> So what you say is this: if there is an open terminal before chmod 700, then
> I can use that terminal to access "apple", but after I close terminal B,
> there is no way to access that apple directory? Neither with a shall window,
> nor with another software?

It is not about the terminal but about the way how you get to directory
/opt/experiment/apple. If you are already in it, then you do not need
to read /opt/experiment where you have no permission.

  $ mkdir experiment
  $ mkdir experiment/apple
  $ cd experiment/apple
  $ chmod a-rwx ..
  $ touch aaa
  $ touch ../../experiment/apple/x
  touch: cannot touch ‘../../experiment/apple/x’: Permission denied
  $ touch ../../experiment/apple/aaa
  touch: cannot touch ‘../../experiment/apple/aaa’: Permission denied
  $ ls -ld ../../experiment/apple
  ls: cannot access ../../experiment/apple: Permission denied
  $ ls -ld .
  drwxr-xr-x 2 thomas thomas 4096 Mar  7 12:38 .

The reason is that nobody is allowed to read ../../experiment and thus
to find ../../experiment/apple where i have permission to write.


> even in the same terminal, vi can't access the file aaa.

My vim can do on the first try.
I can store my edited file and exit vim.

But on the next try i get

  Swap file ".aaa.swp" already exists!

although "ps -ef" confirms that no vim is editing "aaa".
After removing the swap file, i can edit and store again.
Again, the file ".aaa.swp" is not removed.

So vim has a problem with the nailed up parent directory. (Maybe because
it stores its absolute path after having created it by local path ?)


> 1.) To prevent this scenario, I have to do recursive chown and chmod.

At least it would be a less tricky situation.

Equal rights for all files of a tree !
But on the other hand, some files are more equal than others ...


Have a nice day :)

Thomas

Re: File and directory permissions

[epsilon491]

Tomas and Dan, thanks for the explanations. So if the process have already a 
handle (file descriptor) to apple, it can continue using it, even when I chmod 
700 one of its parents. On the other hand, any new process trying to get a 
handle to apple MUST traverse the directory tree. This is what I understand. 
Thanks again for the explanations.

7. Mar 2018 15:05 by to...@tuxteam.de:


> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Wed, Mar 07, 2018 at 11:54:06AM -, Dan Purgert wrote:
>
> [...]
>
>> Think of it as being somewhat like a parking lot / garage with a gate at the
>> entrance.
>
> Uh-oh. A car analogy :)
>
>> You enter the lot / garage, get your ticket, and are admitted in.  Now
>> you're free to go anywhere in the lot to find a space (equivalent of
>> opening / editing files).  
>>
>> While you're driving around the lot, the attendant closes the gate and
>> puts up a "Lot Full" sign [...]
>
> Nice metaphor, thanks!
>
> Cheers
> - -- t
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.12 (GNU/Linux)
>
> iEYEARECAAYFAlqf1ZcACgkQBcgs9XrR2kbOWACdFPkI+DDHLgP7IUmVRWNxktJB
> l0wAn1MoVVSAAQ/X3175kLWFlzvhywhq
> =dG8K
> -END PGP SIGNATURE-

Re: File and directory permissions

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Mar 07, 2018 at 11:54:06AM -, Dan Purgert wrote:

[...]

> Think of it as being somewhat like a parking lot / garage with a gate at the
> entrance.

Uh-oh. A car analogy :)

> You enter the lot / garage, get your ticket, and are admitted in.  Now
> you're free to go anywhere in the lot to find a space (equivalent of
> opening / editing files).  
> 
> While you're driving around the lot, the attendant closes the gate and
> puts up a "Lot Full" sign [...]

Nice metaphor, thanks!

Cheers
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlqf1ZcACgkQBcgs9XrR2kbOWACdFPkI+DDHLgP7IUmVRWNxktJB
l0wAn1MoVVSAAQ/X3175kLWFlzvhywhq
=dG8K
-END PGP SIGNATURE-

Re: File and directory permissions

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Mar 07, 2018 at 12:42:19PM +0100, epsilon...@tutanota.com wrote:
> OK thanks for the explanations.
> To make sure:
> 1.) To prevent this scenario, I have to do recursive chown and chmod.

I don't quite understand what you mean by "scenario": that a process
under the uid of "aristo" can modify the subdirectory "apple"? If you
don't want that, yes, you'll have to change its owner (or group) and
set its permissions accordingly.

> 2.) If I chmod only /opt/experiment, there is absolutely no other way to 
> access apple, other than an already open terminal.

Forget the terminal. It's the shell (in this case: it could be any
process in other cases). There are other ways, see below:

> Correct?

Not quite: try

  su
  cd /opt/experiments/apple
  su aristo
  touch ccc # now I modified dir apple as user aristo

Or better with sudo, anyway:

  sudo -s
  cd /opt/experiments/apple
  sudo -u aristo -s
  touch ccc # now I modified dir apple as user aristo

"You" just need a "helper process" which can traverse experiments and
gives "you" [1] an open descriptor to "apple". There are other ways
to pass open file descriptors around in Unix-like systems. Quite
possibly you can use them in a similar way.

[1] "You" is here just a shorthand for "the process running under the
  aristo UID which can't by itself open the whole path /opt/experiments/apple)

Cheers
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlqf1JMACgkQBcgs9XrR2kaklACfSWlqj3k/6iQwTxYs0RkOZaih
hB4An1eP+iVNa8uy7W1rrgQyS0KA1AIc
=uHKo
-END PGP SIGNATURE-

Re: File and directory permissions

[Dan Purgert]

 wrote:
> Sorry, it is very counter intuitive to me.
> So what you say is this: if there is an open terminal before chmod
> 700, then I can use that terminal to access "apple", but after I close
> terminal B, there is no way to access that apple directory? Neither
> with a shall window, nor with another software?

The shell is already in "apple", so yes it can continue doing things in
that directory. Once you leave (or log out of that terminal), you will
no longer have access.

Think of it as being somewhat like a parking lot / garage with a gate at the
entrance.

You enter the lot / garage, get your ticket, and are admitted in.  Now
you're free to go anywhere in the lot to find a space (equivalent of
opening / editing files).  

While you're driving around the lot, the attendant closes the gate and
puts up a "Lot Full" sign; someone coming in after you (barring them
being one of those "I can use a 'reserved' spot" types) gets turned
away. (or you'll get turned away if you leave, and try re-entering).

> In some cases this may lead to serious security issues, doesn't it?
> Let me ask this specific question: is there any way to access apple,
> otheri than the already open terminal B? If not, then it is ok, but
> there is any w ay to access apple, then I have to do recursive chown
> and chmod to make sure nobody can access anything below /opt/experiment.

No, why would you think that creates a security issue?  

No, once access to apple (or any directory in the chain) is revoked, it
is impossible for users to access the "apple" directory.

-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

Re: File and directory permissions

[epsilon491]

OK thanks for the explanations.
To make sure:
1.) To prevent this scenario, I have to do recursive chown and chmod.
2.) If I chmod only /opt/experiment, there is absolutely no other way to access 
apple, other than an already open terminal.
Correct?

7. Mar 2018 14:34 by to...@tuxteam.de:


> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Wed, Mar 07, 2018 at 12:19:06PM +0100, > epsilon...@tutanota.com>  wrote:
>> Addition to previous email:
>> Example:
>> In terminal B I can still modify a files as follows:
>> touch aaa
>> echo "123" > aaa
>> But when I do,
>> vi aaa
>> even in the same terminal, vi can't access the file aaa.
>
> That's because vi probably converts the path to absolute before
> trying to open it. It wouldn't need to, see the openat() system
> call for how.
>
> Cheers
> - -- tomás
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.12 (GNU/Linux)
>
> iEYEARECAAYFAlqfzl0ACgkQBcgs9XrR2kbInQCeKypOpyRgw6WvzqAUShF/sTX7
> 3sEAnAwqb3Yo4lyQsQ29Yo2108Hvzv2F
> =tvgn
> -END PGP SIGNATURE-

Re: File and directory permissions

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Mar 07, 2018 at 12:19:06PM +0100, epsilon...@tutanota.com wrote:
> Addition to previous email:
> Example:
> In terminal B I can still modify a files as follows:
> touch aaa
> echo "123" > aaa
> But when I do,
> vi aaa
> even in the same terminal, vi can't access the file aaa.

That's because vi probably converts the path to absolute before
trying to open it. It wouldn't need to, see the openat() system
call for how.

Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlqfzl0ACgkQBcgs9XrR2kbInQCeKypOpyRgw6WvzqAUShF/sTX7
3sEAnAwqb3Yo4lyQsQ29Yo2108Hvzv2F
=tvgn
-END PGP SIGNATURE-

Re: File and directory permissions

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Mar 07, 2018 at 12:14:10PM +0100, epsilon...@tutanota.com wrote:
> Sorry, it is very counter intuitive to me.
> So what you say is this: if there is an open terminal before chmod 700,
> then I can use that terminal to access "apple", but after I close terminal
> B, there is no way to access that apple directory?

No. The decisive point is that the first shell has access to the
subdirectory "apple" (via its "current working directory"), while
a new shell can't resolve the whole path "/opt/experiment/apple",
because it will fail at the step "experiment".

> Neither with a shall window, nor with another software?

Any software shares the shell's limitations; after all, it
has to invoke the operating system's services: if it wants to
access this directory by traversing the path -- that's it.

> In some cases this may lead to serious security issues, doesn't it?

Can you make up an example?

> Let me ask this specific question: is there any way to access apple, other 
> than the already open terminal B? If not, then it is ok, but there is any way 
> to access apple, then I have to do recursive chown and chmod to make sure 
> nobody can access anything below /opt/experiment.

The "terminal" is unimportant here. It's the process doing the
access (in your concrete case it's the shell running in the
terminal): it it has already access to the directory in question
(e.g. by an open file descriptor, which it has, courtesy of the
"current working directory"), then just that directory's permission
apply. If you want to travel the whole way down (e.g. in the case
of "open", when provided with a full path), all the intermediate
directories play a role.

Read the manpage. Very instructive.

Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlqfzgQACgkQBcgs9XrR2kYfiwCeLBgYBIFzeWbFa+hPvEpkGtVL
52kAniuOGfVG6rAsNz4XW2JTuAZr7vIG
=fztW
-END PGP SIGNATURE-

Re: File and directory permissions

[epsilon491]

Addition to previous email:
Example:
In terminal B I can still modify a files as follows:
touch aaa
echo "123" > aaa
But when I do,
vi aaa
even in the same terminal, vi can't access the file aaa.

7. Mar 2018 14:14 by epsilon...@tutanota.com:


> Sorry, it is very counter intuitive to me.
> So what you say is this: if there is an open terminal before chmod 700, then 
> I can use that terminal to access "apple", but after I close terminal B, 
> there is no way to access that apple directory? Neither with a shall window, 
> nor with another software?
> In some cases this may lead to serious security issues, doesn't it?
> Let me ask this specific question: is there any way to access apple, other 
> than the already open terminal B? If not, then it is ok, but there is any way 
> to access apple, then I have to do recursive chown and chmod to make sure 
> nobody can access anything below /opt/experiment.
>
> 7. Mar 2018 14:06 by > to...@tuxteam.de> :
>
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On Wed, Mar 07, 2018 at 11:54:43AM +0100, >> epsilon...@tutanota.com>>  
>> wrote:
>>> 7. Mar 2018 11:27 by >>> to...@tuxteam.de>>> :
>>>
>>> > I can't reproduce, either. Once the chown to root happens, non-root
>>> > user can't touch files in directory. Ext4.
>>>
>>> I double checked. Sorry the previous example was not good. To reproduce the 
>>> issue, you have to create another directory inside the top one. Here is a 
>>> working example:
>>>
>>> # terminal A
>>>
>>> su
>>>
>>> mkdir /opt/experiment/
>>>
>>> chown aristo:aristo /opt/experiment
>>>
>>> mkdir /opt/experiment/apple
>>>
>>> chown aristo:aristo /opt/experiment/apple
>>>
>>> # terminal B,
>>>
>>> whoami # aristo
>>>
>>> cd /opt/experiment/apple
>>>
>>> touch aaa # OK
>>
>> So far so good. Not surprising, IMO.
>>
>>> # terminal A
>>>
>>> chown root:root /opt/experiment
>>>
>>> chmod 700 /opt/experiment
>>>
>>>
>>>
>>>
>>> # terminal B
>>>
>>> pwd # Gives /opt/experiment/apple
>>>
>>>
>>> touch bbb # OK bbb is created
>>
>> Also OK. Or is that surprising to you? Aristo has write permissions for
>> apple.
>>
>>> cd /opt/experiment/apple # Gives permission denied
>>
>> That's also OK. While aristo has permissions for apple (x is relevant
>> here), it hasn't for experiment, so it can't "traverse" it.
>>
>>> # new terminal C
>>>
>>> cd /opt/experiment/apple # Denied
>>>
>>> touch /opt/experiment/apple/ccc # Denied
>>
>> Same as above: the resolution of the whole path requires traversing
>> each path's element in turn, and it fails at "experiment". There's
>> even a man page for that: see "man path_resolution" (part of the
>> manpages package).
>>  
>>> Note that, after chmod 700, in terminal B you can still create files, 
>>> although you cannot cd into apple.
>>
>> Yes, it is supposed to work like that.
>>
>> Cheers
>> - -- tomás
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1.4.12 (GNU/Linux)
>>
>> iEYEARECAAYFAlqfx8YACgkQBcgs9XrR2kYdEQCdFdtZP3/AlpzwuUtWJSu8T9V3
>> fb4An3WxROamXckNGTdH8FRaO9H1IFfo
>> =MbqQ
>> -END PGP SIGNATURE-

Re: File and directory permissions

[epsilon491]

Sorry, it is very counter intuitive to me.
So what you say is this: if there is an open terminal before chmod 700, then I 
can use that terminal to access "apple", but after I close terminal B, there is 
no way to access that apple directory? Neither with a shall window, nor with 
another software?
In some cases this may lead to serious security issues, doesn't it?
Let me ask this specific question: is there any way to access apple, other than 
the already open terminal B? If not, then it is ok, but there is any way to 
access apple, then I have to do recursive chown and chmod to make sure nobody 
can access anything below /opt/experiment.

7. Mar 2018 14:06 by to...@tuxteam.de:


> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Wed, Mar 07, 2018 at 11:54:43AM +0100, > epsilon...@tutanota.com>  wrote:
>> 7. Mar 2018 11:27 by >> to...@tuxteam.de>> :
>>
>> > I can't reproduce, either. Once the chown to root happens, non-root
>> > user can't touch files in directory. Ext4.
>>
>> I double checked. Sorry the previous example was not good. To reproduce the 
>> issue, you have to create another directory inside the top one. Here is a 
>> working example:
>>
>> # terminal A
>>
>> su
>>
>> mkdir /opt/experiment/
>>
>> chown aristo:aristo /opt/experiment
>>
>> mkdir /opt/experiment/apple
>>
>> chown aristo:aristo /opt/experiment/apple
>>
>> # terminal B,
>>
>> whoami # aristo
>>
>> cd /opt/experiment/apple
>>
>> touch aaa # OK
>
> So far so good. Not surprising, IMO.
>
>> # terminal A
>>
>> chown root:root /opt/experiment
>>
>> chmod 700 /opt/experiment
>>
>>
>>
>>
>> # terminal B
>>
>> pwd # Gives /opt/experiment/apple
>>
>>
>> touch bbb # OK bbb is created
>
> Also OK. Or is that surprising to you? Aristo has write permissions for
> apple.
>
>> cd /opt/experiment/apple # Gives permission denied
>
> That's also OK. While aristo has permissions for apple (x is relevant
> here), it hasn't for experiment, so it can't "traverse" it.
>
>> # new terminal C
>>
>> cd /opt/experiment/apple # Denied
>>
>> touch /opt/experiment/apple/ccc # Denied
>
> Same as above: the resolution of the whole path requires traversing
> each path's element in turn, and it fails at "experiment". There's
> even a man page for that: see "man path_resolution" (part of the
> manpages package).
>  
>> Note that, after chmod 700, in terminal B you can still create files, 
>> although you cannot cd into apple.
>
> Yes, it is supposed to work like that.
>
> Cheers
> - -- tomás
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.12 (GNU/Linux)
>
> iEYEARECAAYFAlqfx8YACgkQBcgs9XrR2kYdEQCdFdtZP3/AlpzwuUtWJSu8T9V3
> fb4An3WxROamXckNGTdH8FRaO9H1IFfo
> =MbqQ
> -END PGP SIGNATURE-

Re: File and directory permissions

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Mar 07, 2018 at 11:54:43AM +0100, epsilon...@tutanota.com wrote:
> 7. Mar 2018 11:27 by to...@tuxteam.de:
> 
> > I can't reproduce, either. Once the chown to root happens, non-root
> > user can't touch files in directory. Ext4.
> 
> I double checked. Sorry the previous example was not good. To reproduce the 
> issue, you have to create another directory inside the top one. Here is a 
> working example:
> 
> # terminal A
> 
> su
> 
> mkdir /opt/experiment/
> 
> chown aristo:aristo /opt/experiment
> 
> mkdir /opt/experiment/apple
> 
> chown aristo:aristo /opt/experiment/apple
> 
> # terminal B,
> 
> whoami # aristo
> 
> cd /opt/experiment/apple
> 
> touch aaa # OK

So far so good. Not surprising, IMO.

> # terminal A
> 
> chown root:root /opt/experiment
> 
> chmod 700 /opt/experiment
> 
> 
> 
> 
> # terminal B
> 
> pwd # Gives /opt/experiment/apple
> 
> 
> touch bbb # OK bbb is created

Also OK. Or is that surprising to you? Aristo has write permissions for
apple.

> cd /opt/experiment/apple # Gives permission denied

That's also OK. While aristo has permissions for apple (x is relevant
here), it hasn't for experiment, so it can't "traverse" it.

> # new terminal C
> 
> cd /opt/experiment/apple # Denied
> 
> touch /opt/experiment/apple/ccc # Denied

Same as above: the resolution of the whole path requires traversing
each path's element in turn, and it fails at "experiment". There's
even a man page for that: see "man path_resolution" (part of the
manpages package).
 
> Note that, after chmod 700, in terminal B you can still create files, 
> although you cannot cd into apple.

Yes, it is supposed to work like that.

Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlqfx8YACgkQBcgs9XrR2kYdEQCdFdtZP3/AlpzwuUtWJSu8T9V3
fb4An3WxROamXckNGTdH8FRaO9H1IFfo
=MbqQ
-END PGP SIGNATURE-

Re: File and directory permissions

[epsilon491]

7. Mar 2018 11:27 by to...@tuxteam.de:

> I can't reproduce, either. Once the chown to root happens, non-root
> user can't touch files in directory. Ext4.




I double checked. Sorry the previous example was not good. To reproduce the 
issue, you have to create another directory inside the top one. Here is a 
working example:




# terminal A


su

mkdir /opt/experiment/

chown aristo:aristo /opt/experiment

mkdir /opt/experiment/apple

chown aristo:aristo /opt/experiment/apple




# terminal B,

whoami # aristo

cd /opt/experiment/apple

touch aaa # OK




# terminal A

chown root:root /opt/experiment

chmod 700 /opt/experiment




# terminal B

pwd # Gives /opt/experiment/apple


touch bbb # OK bbb is created


cd /opt/experiment/apple # Gives permission denied





# new terminal C

cd /opt/experiment/apple # Denied

touch /opt/experiment/apple/ccc # Denied




Note that, after chmod 700, in terminal B you can still create files, although 
you cannot cd into apple.




 

 

Re: File and directory permissions

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Mar 07, 2018 at 02:46:05PM +1300, Ben Caradoc-Davies wrote:
> On 07/03/18 13:56, epsilon...@tutanota.com wrote:
> >On terminal A,
> >chown root:root /opt/experiment/
> >chmod 700 /opt/experiment
> >On terminal B,
> >whoami #aristo
> >touch bbb
> ># OK bbb is created in /opt/experiment/
> >cd /opt/experiment/
> ># Gives permission denied
> >ls -la
> ># Gives correct listing
> >pwd
> ># Gives /opt/experiment
> 
> I cannot reproduce this behaviour on a local ext4 filesystem. As
> soon as access is removed, a nonprivileged user cannot cd to or list
> contents of the test directory.

I can't reproduce, either. Once the chown to root happens, non-root
user can't touch files in directory. Ext4.

Cheers
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlqfomIACgkQBcgs9XrR2kYFvACfaUppx+DNfR3DdU8HhwuAL+IM
i5UAn0uBEShvWRc/gfk9agkfwFecUpLI
=Nwky
-END PGP SIGNATURE-

Re: File and directory permissions

[epsilon491]

On 07/03/18 13:56, epsilon...@tutanota.com wrote:

 

> Do you have any network filesystems involved in this test?

No network fs.
It is a local LUKS encrypted disk with ext4 filesystem.
Kernel is latest.
Debian 9.3

Re: File and directory permissions

[Ben Caradoc-Davies]

On 07/03/18 13:56, epsilon...@tutanota.com wrote:

On terminal A,
chown root:root /opt/experiment/
chmod 700 /opt/experiment
On terminal B,
whoami #aristo
touch bbb
# OK bbb is created in /opt/experiment/
cd /opt/experiment/
# Gives permission denied
ls -la
# Gives correct listing
pwd
# Gives /opt/experiment


I cannot reproduce this behaviour on a local ext4 filesystem. As soon as 
access is removed, a nonprivileged user cannot cd to or list contents of 
the test directory.


Do you have any network filesystems involved in this test?

Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

File and directory permissions

[epsilon491]

For example, on terminal window A,

su
whoami # root
mkdir /opt/experiment/
chown aristo:aristo /opt/experiment/

Now on another terminal window, B,

su aristo
whoami # aristo
cd /opt/experiment/
touch aaa
# OK aaa is created

On terminal A,

chown root:root /opt/experiment/
chmod 700 /opt/experiment

On terminal B,

whoami #aristo
touch bbb
# OK bbb is created in /opt/experiment/
cd /opt/experiment/
# Gives permission denied
ls -la
# Gives correct listing
pwd
# Gives /opt/experiment

But on a new terminal C,

su aristo
whoami # aristo
cd /opt/experiment/
# Gives permission denied

In the above scenario, note that on terminal B user aristo can still access the 
directory even after the permission is set to 700 by root. Can you clarify the 
reason? Is it an expected behavior? If so why? It looks non-intuitive and 
invites unexpected security issues. If it is not intentional then what is the 
reason of this behavior?

Re: file and directory permissions question...

[Clive Menzies]

On (06/11/03 14:39), [EMAIL PROTECTED] wrote:
> Eric,
> 
>   > /foo   - Only folks in the 'users' group can read, write and delete 
>   > files/dirs.  
> 
> The permissions of directory foo do not influence whether someone can
> open a given file in it for reading or writing, only whether he can
> delete, create, or rename a file. Read permission for the directory
> means you can read what files are in it, e.g. issue the ls command and
> have filename completion. Once someone without read permission to a
> directory /knows/ the exact name of a file that's in it, however, he
> can write to, read, or execute that file if its permissions permit it.
> Precondition to do anything _at_all_ in the directory, however, is to
> have "execute" permission on it (even if you only want to "pass
> through" and do something in a subdirectory).
> 
> Thus, the permissions of directory foo rule who is allowed to enter it
> at all (= "execute" permission), read its contents (the filenames and
> other information about the files) (= read permission), and who is
> allowed to create, rename, or delete files in it (= write permission).
> 
> There are, however, two permission bits, which, when set on a
> directory, influence something beyond this:
> 
> - the sticky bit, when set on a directory, has the effect of
>   restricting write operations on the directory a little more: to
>   delete or rename a file within it, it is no more enough to have
>   write permission to the directory, but you have to be the owner of
>   either the directory or the file (or the superuser, of course).
> 
> - the setgid bit, when set on a directory, causes any new file created
>   in it to take on the group ownership of the directory, rather than
>   the default group of the user who created that file.
> 
> 
> Thus, for directory /foo, you need an ls -l output like this:
> 
> dxrwxrw---   rootusers  foo
> 
> (say 'chmod 770 /foo' and 'chgrp users /foo'). As far as I can see,
> this is the closest you can get to what you want: it allows the owner
> of the directory (arbitrarily root here) and members of the group
> users to create, rename, and delete files inside /foo, as well as get
> information _about_ the files in it. It excludes "the rest of the
> world" from doing anything inside it.
> 
>   > /bar   - Only folks in the 'admin' group can read, write and delete 
>   > files/dirs.
> 
> ditto: (say 'chmod 770 /bar' and 'chgrp admin /bar'.
> 
>   > For both: New files/dirs are created as owner=the person that
>   > created it.
> 
> This is always the case, AFAIK (no permission bit influences that).
> 
>   > New files/dirs are created as group='users'|'admin', respectively.
> 
> Set the setgid bit: say 'chmod 2770 ...' instead of '770'. 
> 
>   > User fred is in groups fred,user
>   > User barney is in group barney
>   > User betty is in groups betty,user,admin
>   > 
>   > I'd like Betty to be able to read/write in both foo and bar.
>   > Barney is hosed, he cannot read or write in neither foo nor bar
>   > I'd like Fred to be able to read/write only in foo.
> 
> That should be achieved here; I think your group assignment is
> logical.
> 
>   > I've tried logging in as betty and touching a new file in bar, but no 
>   > luck (permission denied), even when 
>   > drwxrwx--T   13 admin admin 4096 Nov 05 10:52 bar
> 
> You have set the sticky bit ('chmod 1770 ...' instead of the setgid
> bit, ('chmod 2770 ...'). Permissions in ls -l output must be
> 'drwxrws---', not 'drwxrwx--T'.
> 
> Compare with what is said above: If the sticky bit is set, betty must
> be either the owner of the directory (which is not the case: the owner
> is called admin), the owner of the file (apparently not her), or the
> superuser (apparently not).
> 
Thanks Florian

I learn so much from this list ;)

Regards

Clive

-- 
http://www.clivemenzies.co.uk
strategies for business


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: file and directory permissions question...

[lorian]

Eric,

  > /foo   - Only folks in the 'users' group can read, write and delete 
  > files/dirs.  

The permissions of directory foo do not influence whether someone can
open a given file in it for reading or writing, only whether he can
delete, create, or rename a file. Read permission for the directory
means you can read what files are in it, e.g. issue the ls command and
have filename completion. Once someone without read permission to a
directory /knows/ the exact name of a file that's in it, however, he
can write to, read, or execute that file if its permissions permit it.
Precondition to do anything _at_all_ in the directory, however, is to
have "execute" permission on it (even if you only want to "pass
through" and do something in a subdirectory).

Thus, the permissions of directory foo rule who is allowed to enter it
at all (= "execute" permission), read its contents (the filenames and
other information about the files) (= read permission), and who is
allowed to create, rename, or delete files in it (= write permission).

There are, however, two permission bits, which, when set on a
directory, influence something beyond this:

- the sticky bit, when set on a directory, has the effect of
  restricting write operations on the directory a little more: to
  delete or rename a file within it, it is no more enough to have
  write permission to the directory, but you have to be the owner of
  either the directory or the file (or the superuser, of course).

- the setgid bit, when set on a directory, causes any new file created
  in it to take on the group ownership of the directory, rather than
  the default group of the user who created that file.


Thus, for directory /foo, you need an ls -l output like this:

dxrwxrw---   rootusers  foo

(say 'chmod 770 /foo' and 'chgrp users /foo'). As far as I can see,
this is the closest you can get to what you want: it allows the owner
of the directory (arbitrarily root here) and members of the group
users to create, rename, and delete files inside /foo, as well as get
information _about_ the files in it. It excludes "the rest of the
world" from doing anything inside it.

  > /bar   - Only folks in the 'admin' group can read, write and delete 
  > files/dirs.

ditto: (say 'chmod 770 /bar' and 'chgrp admin /bar'.

  > For both: New files/dirs are created as owner=the person that
  > created it.

This is always the case, AFAIK (no permission bit influences that).

  > New files/dirs are created as group='users'|'admin', respectively.

Set the setgid bit: say 'chmod 2770 ...' instead of '770'. 

  > User fred is in groups fred,user
  > User barney is in group barney
  > User betty is in groups betty,user,admin
  > 
  > I'd like Betty to be able to read/write in both foo and bar.
  > Barney is hosed, he cannot read or write in neither foo nor bar
  > I'd like Fred to be able to read/write only in foo.

That should be achieved here; I think your group assignment is
logical.

  > I've tried logging in as betty and touching a new file in bar, but no 
  > luck (permission denied), even when 
  > drwxrwx--T   13 admin admin 4096 Nov 05 10:52 bar

You have set the sticky bit ('chmod 1770 ...' instead of the setgid
bit, ('chmod 2770 ...'). Permissions in ls -l output must be
'drwxrws---', not 'drwxrwx--T'.

Compare with what is said above: If the sticky bit is set, betty must
be either the owner of the directory (which is not the case: the owner
is called admin), the owner of the file (apparently not her), or the
superuser (apparently not).

Hope this helps,

Florian


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

file and directory permissions question...

[Eric Walstad]

Hi All,

I'm trying to set up some restrictions to a couple of directories and 
their files and just can't seem to get it right.  Here's what I'm 
trying to do:
/foo   - Only folks in the 'users' group can read, write and delete 
files/dirs.  
/bar   - Only folks in the 'admin' group can read, write and delete 
files/dirs.

For both:
New files/dirs are created as owner=the person that created it.  New 
files/dirs are created as group='users'|'admin', respectively.

User fred is in groups fred,user
User barney is in group barney
User betty is in groups betty,user,admin

I'd like Betty to be able to read/write in both foo and bar.
Barney is hosed, he cannot read or write in neither foo nor bar
I'd like Fred to be able to read/write only in foo.

I've tried logging in as betty and touching a new file in bar, but no 
luck (permission denied), even when 
drwxrwx--T   13 admin admin 4096 Nov 05 10:52 bar

Can someone enlighten me with a chmod command or two that'll make this 
happen?  Do I need to change the groups to which the users belong?

It probably doesn't matter, but I'm running Debain 'unstable'.

Many thanks in advance.

Eric.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]