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?

Changes in the way tar(1) constructs directory permissions

[John Conover]

There has been changes in the way a tar(1) restore to a temporary
directory constructs directory ownerships; as login theuser, in
${HOME}:

mkdir xxx xxx/yyy; touch xxx/yyy/zzz
su
Password:
# cd /
# tar cvf home/theuser/aaa.tar home/theuser/xxx
  home/theuser/xxx/
  home/theuser/xxx/yyy/
  home/theuser/xxx/yyy/zzz
# cd /home/theuser/
# mv xxx xxx.bak
# tar xvf aaa.tar
  home/theuser/xxx/
  home/theuser/xxx/yyy/
  home/theuser/xxx/yyy/zzz
# ls -al home /home

  /home:
  total
  drwxr-xr-x  6 rootroot 4096 Nov  6 23:52 ./
  drwxr-xr-x 28 rootroot 4096 Nov  7 10:41 ../
  drwxr-xr-x 72 theuser users16384 Nov  8 00:14 theuser/

  home:
  total
  drwxr-xr-x  3 root root   4096 Nov  8 00:14 ./
  drwxr-xr-x 72 theuser users 16384 Nov  8 00:14 ../
  drwxr-xr-x  3 root root   4096 Nov  8 00:14 theuser/
^
^
^

I verified that the ownership of the restored directory, theuser/, was
correct in a 2012 version of Linux.

John

-- 

John Conover, cono...@rahul.net, http://www.johncon.com/


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141108083251.16945.qm...@rahul.net

Re: Changes in the way tar(1) constructs directory permissions

[Don Armstrong]

On Sat, 08 Nov 2014, John Conover wrote:
 There has been changes in the way a tar(1) restore to a temporary
 directory constructs directory ownerships; as login theuser, in
 ${HOME}:

This looks like you're using tar --no-same-owner, possibly via an ENV
variable or something else.

% fakeroot bash -c 'touch foo; chown 9 foo; ls -l foo; tar -zcf bar.tar.gz foo; 
rm foo; tar -zxf bar.tar.gz; ls -l foo; rm foo';
-rw-r--r-- 1 news root 0 Nov  8 09:43 foo
-rw-r--r-- 1 news root 0 Nov  8 09:43 foo

works just fine here with tar 1.27.1-2.
 

-- 
Don Armstrong  http://www.donarmstrong.com

First you take a drink,
then the drink takes a drink,
then the drink takes you.
 -- F. Scott Fitzgerald


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141108174630.gt29...@teltox.donarmstrong.com

Re: Changes in the way tar(1) constructs directory permissions

[John Conover]

Don Armstrong writes:
 On Sat, 08 Nov 2014, John Conover wrote:
  There has been changes in the way a tar(1) restore to a temporary
  directory constructs directory ownerships; as login theuser, in
  ${HOME}:
 
 This looks like you're using tar --no-same-owner, possibly via an ENV
 variable or something else.
 
 % fakeroot bash -c 'touch foo; chown 9 foo; ls -l foo; tar -zcf bar.tar.gz 
 foo; rm foo; tar -zxf bar.tar.gz; ls -l foo; rm foo';
 -rw-r--r-- 1 news root 0 Nov  8 09:43 foo
 -rw-r--r-- 1 news root 0 Nov  8 09:43 foo


That's true, Don, but the issue is the ownership of the DIRECTORIES
when installing, a directory TREE in a non root temporary
directory. The file ownerships are, indeed, correct. The ownerships of
the directories down to the files are always root/root.

John

-- 

John Conover, cono...@rahul.net, http://www.johncon.com/


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141108183615.6763.qm...@rahul.net

Re: Changes in the way tar(1) constructs directory permissions

[Don Armstrong]

On Sat, 08 Nov 2014, John Conover wrote:
 That's true, Don, but the issue is the ownership of the DIRECTORIES
 when installing, a directory TREE in a non root temporary directory.
 The file ownerships are, indeed, correct. The ownerships of the
 directories down to the files are always root/root.

% fakeroot bash -c 'mkdir -p foo/bar; chown 8:8 .; chown 9:9 foo; chown 10:10 
foo/bar; ls -la foo; tar -zvvtf bar.tar.gz; tar -zcf bar.tar.gz foo; rmdir -p 
foo/bar; tar -zxf bar.tar.gz; ls -la foo; rmdir -p foo/bar;';
total 12
drwxr-xr-x 3 news news 4096 Nov  8 11:07 .
drwxr-xr-x 7 mail mail 4096 Nov  8 11:07 ..
drwxr-xr-x 2 uucp uucp 4096 Nov  8 11:07 bar
drwxr-xr-x news/root 0 2014-11-08 11:07 foo/
drwxr-xr-x uucp/root 0 2014-11-08 11:07 foo/bar/
total 12
drwxr-xr-x 3 news news 4096 Nov  8 11:07 .
drwxr-xr-x 7 mail mail 4096 Nov  8 11:07 ..
drwxr-xr-x 2 uucp uucp 4096 Nov  8 11:07 bar

It would be helpful if you provided a self-contained example like this
which showed the behavior you are seeing.

It would also be useful to see the output of env|grep -i TAR; the output
of tar --version; and the output of dpkg -l tar;.

-- 
Don Armstrong  http://www.donarmstrong.com

LEADERSHIP -- A form of self-preservation exhibited by people with
autodestructive imaginations in order to ensure that when it comes to
the crunch it'll be someone else's bones which go crack and not their
own. 
 -- The HipCrime Vocab by Chad C. Mulligan 
(John Brunner _Stand On Zanzibar_ p256-7)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141108191008.gu29...@teltox.donarmstrong.com

Re: Changes in the way tar(1) constructs directory permissions

[John Conover]

Don Armstrong writes:
 On Sat, 08 Nov 2014, John Conover wrote:
  That's true, Don, but the issue is the ownership of the DIRECTORIES
  when installing, a directory TREE in a non root temporary directory.
  The file ownerships are, indeed, correct. The ownerships of the
  directories down to the files are always root/root.


su
cd /
tar cvf xxx.tar etc/cups/printers.conf
cd
tar xvf /xxx.tar
ls -al etc

and look at the ownership of the cups directory and compare it to the
ownership in /etc.

This is a changed behavior in tar(1), (at least from Ubuntu 10.04 LTS,
which I just verified.)

Note that it only happens when when tar'ing file names in a directory,
and not the directory itself, (tar cvf xxx.tar etc/cups, and restoring,
everything has the correct ownership/permissions.)

See, also:


http://www.gnu.org/software/tar/manual/html_node/Directory-Modification-Times-and-Permissions.html

for some details, where it would seem that the behavior is
acceptable-at issue is that it changed between the last versions of
Linux, and the newer.

Thanks, Don,

John

-- 

John Conover, cono...@rahul.net, http://www.johncon.com/


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141108194012.9306.qm...@rahul.net

Re: Changes in the way tar(1) constructs directory permissions

[Don Armstrong]

On Sat, 08 Nov 2014, John Conover wrote:
 and look at the ownership of the cups directory and compare it to the
 ownership in /etc.

In this example, you're not archiving etc/cups or etc, you're just
archiving etc/cups/printers.conf, which means that tar must create
etc/cups itself, and has no record of what the original permissions of
etc/cups were.

I've verified that this behaves the same way in 1.23-3 and 1.26+dfsg-0.1
as it does in 1.27-1.

If you want to keep the permissions of etc/cups, then you want:

sudo bash -c 'tar -C / --no-recursion -cvf xxx.tar.gz etc/cups/printers.conf 
etc/cups; tar -vtf xxx.tar.gz; tar -vxf xxx.tar.gz; ls -lR etc;'
 
 for some details, where it would seem that the behavior is
 acceptable-at issue is that it changed between the last versions of
 Linux, and the newer.

I have no idea what you mean by last versions of Linux. The output of
dpkg -l tar; or tar --version; will tell us what version(s) of tar
you're using.

-- 
Don Armstrong  http://www.donarmstrong.com

It's not Hollywood. War is real, war is primarily not about defeat or
victory, it is about death. I've seen thousands and thousands of dead
bodies. Do you think I want to have an academic debate on this
subject?
 -- Robert Fisk


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141108201110.gw29...@teltox.donarmstrong.com

[Fwd: Debian Network Installation Insecure Default Directory Permissions]

[Peterson Raydan Fontes Ursine]

---BeginMessage---
http://secunia.com/advisories/19331/


Luciano Ricardo Mendonça - MCSE, CNE
Phone: +55(31)3484-2107
PGP Key ID: 0x0AE40422
Fingerprint: C1C0E4FE0C6F8901AAF7-E7D6EFEC63B50AE40422


---End Message---

Directory Permissions

[Ben Bettin]

I'm running Sarge and have two 250 gb drives.  One has my system
installed on it, the other is mounted as /backup.  I intended to use
/backup to...well...back things up :)

How do I grant certain users access to /backup?  Right now it's only
accessible to the root user.  I've read through a few man-pages, and I
get the impression that I need to add the users to the directory's
groupbut I'm not sure how to do that.  Any thoughts?

Thanks in advance!


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

Re: Directory Permissions

[Andreas Janssen]

Hello

Ben Bettin ([EMAIL PROTECTED]) wrote:

 I'm running Sarge and have two 250 gb drives.  One has my system
 installed on it, the other is mounted as /backup.  I intended to use
 /backup to...well...back things up :)
 
 How do I grant certain users access to /backup?  Right now it's only
 accessible to the root user.  I've read through a few man-pages, and I
 get the impression that I need to add the users to the directory's
 groupbut I'm not sure how to do that.  Any thoughts?

If you use the FAT file system on the backup disk, set permissions,
owner and group with the umask, uid and gid parameters in the fstab.
`man mount` can tell you the details. If you use a Linux file system on
the backup drive, set the permissions using chmod, chown and chgrp.

best regards
 Andreas Janssen

-- 
Andreas Janssen [EMAIL PROTECTED]
PGP-Key-ID: 0xDC801674 ICQ #17079270
Registered Linux User #267976
http://www.andreas-janssen.de/debian-tipps-sarge.html


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

Re: Directory Permissions

[Kent West]

Ben Bettin wrote:
I'm running Sarge and have two 250 gb drives.  One has my system
installed on it, the other is mounted as /backup.  I intended to use
/backup to...well...back things up :)
How do I grant certain users access to /backup?  Right now it's only
accessible to the root user.  I've read through a few man-pages, and I
get the impression that I need to add the users to the directory's
groupbut I'm not sure how to do that.  Any thoughts?
Thanks in advance!
 

Create a group (or use an existing one - see /etc/group), like so:
 addgroup backupers
Then add your users to that group; either edit /etc/group or adduser 
person backupers.

Change the perms on the directory, like so:
chown -R root.backupers /backup
chmod -r g+rw /backup
Now all members in the backupers group have read/write access to 
/backup.

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

Re: Directory Permissions

[Joao Clemente]

Ben Bettin wrote:
I'm running Sarge and have two 250 gb drives.  One has my system
installed on it, the other is mounted as /backup.  I intended to use
/backup to...well...back things up :)
How do I grant certain users access to /backup?  Right now it's only
accessible to the root user.  I've read through a few man-pages, and I
get the impression that I need to add the users to the directory's
groupbut I'm not sure how to do that.  Any thoughts?
Hmmm I'm doing this by head, plese give it a little brain power if 
these instructions are not 100% accurate.

I think it sufices:
1 - create group backup_users
# groupadd backup_users
2 - put wanted user in group, by editing /etc/group
...
backup_users:x:34:user1,user23,user64
...
3 - give permissions to directory
chown -R root.backup_users /backup
chmod -R 660 /backup
Actually, there is already a backup group in the system, but I dunno 
exctly if it's already there for some specific purpose or not...

Good luck!
Joao Clemente
--
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---   rootusersdate  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]

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---   rootusersdate  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]

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]

httpd user and user directory permissions dilemna

[David Christensen]

[EMAIL PROTECTED]  [EMAIL PROTECTED]:

I am running Apache 1.3.26 on Debian 3.0r1 (Woody).  I would like to
enable user ~/public_html directories, but have two security goals which
I cannot solve simultaneously:

1.  Apache should run as the user when reading user pages and running
user CGI scripts.

2.  User home directories should not allow group or world access.


Using the default Debian configuration, placing content into
/home/dpchrist/public_html and browsing to
http://192.168.254.2/~dpchrist/ works just fine.  Enabling per-user
~/public_html/cgi-bin directories in httpd.conf and invoking whoami
from a CGI script in /home/dpchrist/public_html/cgi-bin reports
dpchrist, confirming that goal #1 is met (I'm not sure of the
mechanics, but assume that Apache is making seteuid() and setegid()
system calls at some point before processing the CGI script).  However,
the default Debian home directory permissions are 755, failing goal #2.


When I change my home directory permissions to 700 to meet goal #2,
Apache fails with Forbidden You don't have permission to access
/~dpchrist/ on this server. Apache/1.3.26 Server at 192.168.254.2 Port
80.


I don't understand why Apache cannot access my files and folders when
running as my userid.  Does anybody know the explanation?


Does anyone know how to meet both goals simultaneously?


TIA,

David



[EMAIL PROTECTED]:~/d3020g/etc/apache# grep -v '^ *#' httpd.conf | grep -v
'^$'
ServerType standalone
ServerRoot /etc/apache
LockFile /var/lock/apache.lock
PidFile /var/run/apache.pid
ScoreBoardFile /var/run/apache.scoreboard
Timeout 300
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 15
MinSpareServers 5
MaxSpareServers 10
StartServers 5
MaxClients 150
MaxRequestsPerChild 100
LoadModule config_log_module /usr/lib/apache/1.3/mod_log_config.so
LoadModule config_log_module /usr/lib/apache/1.3/mod_log_config_ssl.so
LoadModule mime_magic_module /usr/lib/apache/1.3/mod_mime_magic.so
LoadModule mime_module /usr/lib/apache/1.3/mod_mime.so
LoadModule mime_module /usr/lib/apache/1.3/mod_mime_ssl.so
LoadModule negotiation_module /usr/lib/apache/1.3/mod_negotiation.so
LoadModule status_module /usr/lib/apache/1.3/mod_status.so
LoadModule autoindex_module /usr/lib/apache/1.3/mod_autoindex.so
LoadModule dir_module /usr/lib/apache/1.3/mod_dir.so
LoadModule cgi_module /usr/lib/apache/1.3/mod_cgi.so
LoadModule userdir_module /usr/lib/apache/1.3/mod_userdir.so
LoadModule alias_module /usr/lib/apache/1.3/mod_alias.so
LoadModule rewrite_module /usr/lib/apache/1.3/mod_rewrite.so
LoadModule access_module /usr/lib/apache/1.3/mod_access.so
LoadModule auth_module /usr/lib/apache/1.3/mod_auth.so
LoadModule expires_module /usr/lib/apache/1.3/mod_expires.so
LoadModule unique_id_module /usr/lib/apache/1.3/mod_unique_id.so
LoadModule setenvif_module /usr/lib/apache/1.3/mod_setenvif.so
ExtendedStatus On
Port 80
User www-data
Group www-data
ServerAdmin [EMAIL PROTECTED]
ServerName 192.168.254.2
DocumentRoot /var/www
Directory /
Options SymLinksIfOwnerMatch
AllowOverride None
/Directory
Directory /var/www/
Options Indexes Includes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
Allow from all
/Directory
IfModule mod_userdir.c
UserDir public_html
/IfModule
Directory /home/*/public_html
AllowOverride FileInfo AuthConfig Limit
Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
Limit GET POST OPTIONS PROPFIND
Order allow,deny
Allow from all
/Limit
Limit PUT DELETE PATCH PROPPATCH MKCOL COPY MOVE LOCK UNLOCK
Order deny,allow
Deny from all
/Limit
/Directory
Directory /home/*/public_html/cgi-bin
Options +ExecCGI
/Directory
IfModule mod_dir.c
DirectoryIndex index.html index.htm index.shtml index.cgi
/IfModule
AccessFileName .htaccess
Files ~ ^\.ht
Order allow,deny
Deny from all
/Files
UseCanonicalName On
TypesConfig /etc/mime.types
DefaultType text/plain
IfModule mod_mime_magic.c
MIMEMagicFile share/magic
/IfModule
HostnameLookups Off
ErrorLog /var/log/apache/error.log
LogLevel warn
LogFormat %h %l %u %t \%r\ %s %b \%{Referer}i\ \%{User-Agent}i\
%T %v f
ull
LogFormat %h %l %u %t \%r\ %s %b \%{Referer}i\ \%{User-Agent}i\
%P %T d
ebug
LogFormat %h %l %u %t \%r\ %s %b \%{Referer}i\ \%{User-Agent}i\
combine
d
LogFormat %h %l %u %t \%r\ %s %b common
LogFormat %{Referer}i - %U referer
LogFormat %{User-agent}i agent
CustomLog /var/log/apache/access.log combined
ServerSignature On
Alias /icons/ /usr/share/apache/icons/
Directory /usr/share/apache/icons
Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all
/Directory
ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
Directory /usr/lib/cgi-bin/
AllowOverride None
Options ExecCGI
Order allow,deny
Allow from all
/Directory
IfModule mod_autoindex.c
IndexOptions FancyIndexing NameWidth=*
AddIconByEncoding (CMP,/icons/compressed.gif) x-compress x-gzip
AddIconByType (TXT,/icons

Re: [users@httpd] httpd user and user directory permissions dilemna

[Joshua Slive]

On Sun, 2 Nov 2003, David Christensen wrote:

 [EMAIL PROTECTED]  [EMAIL PROTECTED]:

 I am running Apache 1.3.26 on Debian 3.0r1 (Woody).  I would like to
 enable user ~/public_html directories, but have two security goals which
 I cannot solve simultaneously:

 1.  Apache should run as the user when reading user pages and running
 user CGI scripts.

 2.  User home directories should not allow group or world access.


Neither of these is possible because of the basic limitations of unix
security.

As you already figured out, you can accomplish part of 1, because suexec
can launch cgi scripts as the user.  The reading user pages part is
impossible, however, and any directory serving web pages must be in some
way accessible by the web server, so 2 isn't possible either.

Why?  Well, under unix, each program must run as a user.  To make apache
more secure, all request processing and serving is done under a
non-root userid (see the User and Group directives).  Obviously, a
non-root userid can't simply switch to some other userid.

Even if you were to run apache as root (not a good move!), this still
wouldn't work.  Each apache process serves many different requests.  If
the process were to switch to a non-root userid to serve a specific
directory, then it couldn't serve requests for any other directory,
because there is no way to get the root permissions back to switch to the
new user.  You could imagine a server that forked a new process to serve
each request, which then exited.  But you can also imagine that such a
server would be dog-slow.

Solutions?  Well, there have been a couple different projects that use the
new threading ability of apache 2 to allow different pools of threads to
be kept around to serve requests under different userids.  This wouldn't
work for dozens or hundreds of different userids, of course.  And none of
these projects has anything production ready.  See the perchild mpm,
which doesn't work.

You could do the same thing by running a number of different instances of
apache on different ports with different privileges and using a reverse
proxy to choose which one gets the requests.  Again, this would be rather
resource intensive and complicated.

The punch-line: you can't do that.  CGI scripts can be launched under
different userids, but ordinary pages (including php scripts launched as
part of the apache process) must use the apache userid.  Hence you need to
provide world or apache-group read and search access to all the files you
want to serve.

(That was probably way more than you wanted to know.  I should put that
into the FAQ so I don't have to repeat it!)

Joshua.


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

Re: Directory permissions

[Haralambos Geortgilakis]

Yo Madduck,

luv that handle! Donald Duck is one of my favz @ Disney!

Now, where was I? Debian Tux

snip
haralambos@haralambos:~$ ld -ld / /Hellene
ld: cannot find -ld
haralambos@haralambos:~$ su
Password:
haralambos:/home/haralambos# ld -ld / /Hellene
ld: cannot find -ld
haralambos:/home/haralambos# ld -ld 
ld: cannot find -ld
haralambos:/home/haralambos#
snip

ld -ld / /Hellene

I am puzzled why you recommended the linker-which I needed to look up?

Mounting the partition is a snap. While in either Konq or Gnome 
Commander or Nautilus or Midnight Commander, I try to change the 
Permissions of a directory  it's subdirectories, so I as a plain user, 
can write to that directory.

When I use all the above, as root, I get an error message back, say root 
does not have permission to change the permissions. I've tried to 
read info/man on chown  chmod  I am afraid that as a Geek of very 
little brain, they did not make sense to me.

Do you know what I mean, gov?

To wit, help please.

*BFN*

Greek Geek  :-)


While having never invented a sin, I'm trying to perfect several.



martin f krafft wrote:

also sprach Haralambos Geortgilakis [EMAIL PROTECTED] [2002.11.18.1219 +0100]:
 

snip
haralambos:/Hellene# cd Stuff
haralambos:/Hellene/Stuff# ls -ld
drwxr-xr-x   38 root root24576 Aug 12 21:09 .
haralambos:/Hellene/Stuff#
snip
   


so /Hellene is a VFAT partition? can you give me

 * ld -ld / /Helene
 * mount

what exactly are you trying to do (give me the commands) and what
exactly are the errors?

 




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

Re: Directory permissions

[martin f krafft]

also sprach Haralambos Geortgilakis [EMAIL PROTECTED] [2002.11.19.1022 +0100]:
 haralambos@haralambos:~$ ld -ld / /Hellene

ls I meant sorry..

-- 
 .''`. martin f. krafft [EMAIL PROTECTED]
: :'  :proud Debian developer, admin, and user
`. `'`
  `-  Debian - when you have better things to do than fixing a system



msg13954/pgp0.pgp
Description: PGP signature

Directory permissions

[Haralambos Geortgilakis]

Hi yall,

sometimes I read the howto's  they make sense  sometimes they don't

Well, I tried to change them in the KDE file manager  Midnight 
Commander (God I love MC!), as root  it said I could not; insufficient 
permission! Hmmm.

So, I have a directory, on a Win-FAT-32 partition, with various 
sub-directories  I wanna access then as a plain user.

Um, like what is the syntax dude/dudette?

*BFN*

Greek Geek  :-)



Q: What algorithm did Intel use in the Pentium's floating point divider?
A: Life is like a box of chocolates... (Source: F. Gump of Intel)



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

Re: Directory permissions

[martin f krafft]

also sprach Haralambos Geortgilakis [EMAIL PROTECTED] [2002.11.18.1110 +0100]:
 So, I have a directory, on a Win-FAT-32 partition, with various 
 sub-directories  I wanna access then as a plain user.

show me the `ls -ld ` on that directory.

-- 
 .''`. martin f. krafft [EMAIL PROTECTED]
: :'  :proud Debian developer, admin, and user
`. `'`
  `-  Debian - when you have better things to do than fixing a system



msg13648/pgp0.pgp
Description: PGP signature

Re: Directory permissions

[Haralambos Geortgilakis]

Hi Yall  Martin,

here is a wee screen dump

snip
haralambos:/Hellene# cd Stuff
haralambos:/Hellene/Stuff# ls -ld
drwxr-xr-x   38 root root24576 Aug 12 21:09 .
haralambos:/Hellene/Stuff#
snip

Must crash-it is late on this side of the planet.  :-)

*BFN*

H  :-)

Seen in a watch shop:  PLEASE WAIT PATIENTLY TO BE SERVED. I ONLY HAVE 
TWO HANDS



martin f krafft wrote:

also sprach Haralambos Geortgilakis [EMAIL PROTECTED] [2002.11.18.1110 +0100]:
 

So, I have a directory, on a Win-FAT-32 partition, with various 
sub-directories  I wanna access then as a plain user.
   


show me the `ls -ld ` on that directory.

 




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

Re: Directory permissions

[martin f krafft]

also sprach Haralambos Geortgilakis [EMAIL PROTECTED] [2002.11.18.1219 +0100]:
 snip
 haralambos:/Hellene# cd Stuff
 haralambos:/Hellene/Stuff# ls -ld
 drwxr-xr-x   38 root root24576 Aug 12 21:09 .
 haralambos:/Hellene/Stuff#
 snip

so /Hellene is a VFAT partition? can you give me

  * ld -ld / /Helene
  * mount

what exactly are you trying to do (give me the commands) and what
exactly are the errors?

-- 
 .''`. martin f. krafft [EMAIL PROTECTED]
: :'  :proud Debian developer, admin, and user
`. `'`
  `-  Debian - when you have better things to do than fixing a system



msg13687/pgp0.pgp
Description: PGP signature

Re: Directory permissions

[sean finney]

hiya,

On Mon, Nov 18, 2002 at 12:41:42PM +0200, [EMAIL PROTECTED] wrote:
/dev/hda1   /mnt/win1   vfatdefaults,ro,user,noauto 0   0

not to be picky, but just to point it out, having sub-directories in
/mnt is non-standard (well, to most linuces/unices, redhat seems to
have other opinions on the matter) and non-FHS compliant.  of course
this is your machine, so you can do whatever you want, and you wont face
any consequences for doing it this way, but if you ever end up jointly
administering a machine, this could result in headaches.  if it's
something you intend to have mounted for more than just a short amount
of time, i'd put it somewhere like /windows or /usr/local/win or
something.

also, i agree with the ro setting.  yes, read-write works, but i don't
trust the filesystem format itself and would prefer to touch it as
little as possible.  in the few cases i need to change stuff on my vfat
partition, i remount it with mount -o 'remount,rw' /pathname


--sean



msg13705/pgp0.pgp
Description: PGP signature

Re: Directory permissions

[martin f krafft]

 of time, i'd put it somewhere like /windows or /usr/local/win or
 something.

/windows? that's a direct violation of the FHS. just being picky as
you were.

-- 
 .''`. martin f. krafft [EMAIL PROTECTED]
: :'  :proud Debian developer, admin, and user
`. `'`
  `-  Debian - when you have better things to do than fixing a system



msg13718/pgp0.pgp
Description: PGP signature

Re: Directory permissions

[sean finney]

On Mon, Nov 18, 2002 at 04:51:15PM +0100, martin f krafft wrote:
 /windows? that's a direct violation of the FHS. just being picky as
 you were.

does it?  i didn't think it did since the reason listed in the fhs for
not putting more stuff in / is to keep it small and thus less likely
to corrupt and/or fill.  also, reading through the fhs i don't see any
mention of /cdrom either, which is debian-provided in / and also a
mountpoint, right?  please correct me if i'm wrong!

that brings up a question i've been wondering:  is the FHS merely a
guideline that debian packages follow, or is it something that debian
users are also strongly recommended to follow as well?  granted i might
be a hypocrite for nitpicking one fhs violation and suggesting another,
but having /music symlinked to /usr/local/music saves my poor hands
unwanted keystrokes.

--sean



msg13741/pgp0.pgp
Description: PGP signature

Re: Directory permissions

[Colin Watson]

On Mon, Nov 18, 2002 at 12:51:05PM -0500, sean finney wrote:
 that brings up a question i've been wondering:  is the FHS merely a
 guideline that debian packages follow, or is it something that debian
 users are also strongly recommended to follow as well?

Debian users can do what they like, although they'd be best advised to
stay out of regions managed by the Debian package management system.
Apart from that, the FHS should really only be considered to bind what
distributions do.

-- 
Colin Watson  [[EMAIL PROTECTED]]


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

home directory permissions

[Charlie Grosvenor]

Hi
I have just used the command adduser to add some users to my system. I
have noticed that each user added has read rights to other users home
directory. Why is this? how can i stop adduser from creating home
directories with these permissions?

Thankyou

Charlie

Re: home directory permissions

[Gary Hennigan]

Charlie Grosvenor [EMAIL PROTECTED] writes:
 I have just used the command adduser to add some users to my system. I
 have noticed that each user added has read rights to other users home
 directory. Why is this? how can i stop adduser from creating home
 directories with these permissions?

On most of the systems I've ever administered that was the desired
permission. Maybe just historical, but I can tell stories all day
about users wanting to access each others directories and weren't able
to because they had set there root directory permission to 700.

Anyway, you were either asked whether the default should be to have
home directories system-wide readable or you've set you're priority to
a value high enough that it used the default when you installed
adduser. You can reconfigure it like:

dpkg-reconfigure --priority=low adduser

and answer No to the question Do you want system wide readable home
directories?.

This assumes you're running testing or unstable. I don't remember
if this was configurable via dpkg-reconfigure in potato.

Gary

Re: home directory permissions

[Daniel Kleine-Albers]

Hello Charlie,

dpkg-reconfigure adduser
It asks you, if you want this behaviour or not.

Daniel


Charlie Grosvenor wrote:

Hi
I have just used the command adduser to add some users to my system. I
have noticed that each user added has read rights to other users home
directory. Why is this? how can i stop adduser from creating home
directories with these permissions?

Thankyou

Charlie

Re: home directory permissions

[Xeno Campanoli]

Gary Hennigan wrote:
 
 Charlie Grosvenor [EMAIL PROTECTED] writes:
  I have just used the command adduser to add some users to my system. I
  have noticed that each user added has read rights to other users home
  directory. Why is this? how can i stop adduser from creating home
  directories with these permissions?

Actually, I think you just change the permissions in the file
/etc/skel.  I'm not sure though, so let us all know if that works. 
There may be a umask thing you'll want to change too.
-- 
http://www.eskimo.com/~xeno
[EMAIL PROTECTED]
Physically I'm at:  5101 N. 45th St., Tacoma, WA, 98407-3717, U.S.A.

Re: home directory permissions

[Hans Ekbrand]

On Tue, Mar 05, 2002 at 11:11:55AM -0700, Gary Hennigan wrote:
 Charlie Grosvenor [EMAIL PROTECTED] writes:
  I have just used the command adduser to add some users to my system. I
  have noticed that each user added has read rights to other users home
  directory. Why is this? how can i stop adduser from creating home
  directories with these permissions?
 
 On most of the systems I've ever administered that was the desired
 permission. Maybe just historical, but I can tell stories all day
 about users wanting to access each others directories and weren't able
 to because they had set there root directory permission to 700.
 
 Anyway, you were either asked whether the default should be to have
 home directories system-wide readable or you've set you're priority to
 a value high enough that it used the default when you installed
 adduser. You can reconfigure it like:
 
 dpkg-reconfigure --priority=low adduser
 
 and answer No to the question Do you want system wide readable home
 directories?.
 
 This assumes you're running testing or unstable. I don't remember
 if this was configurable via dpkg-reconfigure in potato.
 
 Gary

Thanks Gary for a very informative answer. Can I send a revised version
to [EMAIL PROTECTED] for inclusion in the Debian FAQ?

-- 
Note that I use Debian version 3.0
Linux emac140 2.4.17 #1 s?n feb 10 20:21:22 CET 2002 i686 unknown

Hans Ekbrand

pgpP4VwJlhTNz.pgp
Description: PGP signature

Re: home directory permissions

[Dave Sherohman]

On Tue, Mar 05, 2002 at 11:20:10AM -0800, Xeno Campanoli wrote:
 Gary Hennigan wrote:
  Charlie Grosvenor [EMAIL PROTECTED] writes:
   I have just used the command adduser to add some users to my system. I
   have noticed that each user added has read rights to other users home
   directory. Why is this? how can i stop adduser from creating home
   directories with these permissions?
 
 Actually, I think you just change the permissions in the file
 /etc/skel.  I'm not sure though, so let us all know if that works. 

Changing the permissions on the files in /etc/skel, which are copied
into the new user's home directory, is very unlikely to affect the
permissions on the directory they're copied into.

It's interesting, though, that everyone is saying to use dpkg to
reconfigure adduser...  IIRC, that only works for woody and sid,
where you can instead edit /etc/adduser.conf and set DIR_MODE to
whatever permissions you want (0755, 0700, 0750 seem like reasonable
choices) for user home directories.  potato doesn't appear to have a
config switch to control this, but /usr/sbin/adduser is just a shell
script, so you can search through it for the string 0755 and change
it - although this will have to be repeated whenever you install a
new version of adduser.

-- 
When we reduce our own liberties to stop terrorism, the terrorists
have already won. - reverius

Innocence is no protection when governments go bad. - Tom Swiss

Re: home directory permissions

[Xeno Campanoli]

Xeno Campanoli wrote:
 Actually, I think you just change the permissions in the file

Sorry!  I meant in the directory /etc/skel!  Bleh!

 /etc/skel.  I'm not sure though, so let us all know if that works.
 There may be a umask thing you'll want to change too.

-- 
http://www.eskimo.com/~xeno
[EMAIL PROTECTED]
Physically I'm at:  5101 N. 45th St., Tacoma, WA, 98407-3717, U.S.A.

Re: Correct directory permissions list?

[Torsten Hilbrich]

[EMAIL PROTECTED] writes:

 Hi all,
 
 Somehow several directories on my 1.3.1 system have had their
 permissions changed.  So far I have found /tmp and /var/spool.  Is
 there some list somewhere that lists all the default permissions of
 these directories? Maybe a file in /etc or something?  I think it
 happened when I tried to use the netscape4 package to upgrade
 netscape 4.04 to 4.05 and it crapped out.

The permissions of /tmp are likely to be changed if you:

cd /tmp
tar xfz ...

As the tar archive contains an entry for the current directory, the
/tmp directory gets usually permissons of 755 after this.

No idea what might happend to /var/spool.

To answer your question, I don't know of such a file permission list
(except for suid programs).  The base-files package, for example,
contains the /tmp directory including its correct permission, but the
permissions are not part of the /var/lib/dpkg/info/base-files.list
file.

Torsten


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

Correct directory permissions list?

[servis]

Hi all,

Somehow several directories on my 1.3.1 system have had their
permissions changed.  So far I have found /tmp and /var/spool.  Is
there some list somewhere that lists all the default permissions of
these directories? Maybe a file in /etc or something?  I think it
happened when I tried to use the netscape4 package to upgrade netscape
4.04 to 4.05 and it crapped out.

Thanks,
 
Brian 
-- 
Mechanical Engineering  [EMAIL PROTECTED]
Purdue University   http://www.ecn.purdue.edu/~servis


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

Re: Directory permissions.

[wb2oyc]

On 13:28:43 Nathan E Norman wrote:

Using the correct tools is important.  David gives you one such tool - I
personally type the following command in the directory I wish to copy:
find . -print | cpio -p /target.  This is of course a simplification;
find and cpio have a lot of powerful options, and people will argue the 
merits of tar vs. cpio all day.  It works for me.  At any rate, mc is not
up to the task.

For an even more precise duplicate of a directory hierarchy I've used
this:

find . -depth | cpio -pdmv /target

This will create an exact duplicate and traverse any sub-dir's, preserving
symlinks, permissions, and dates of everything from the current directory
down thru the tree.  I've used this many times moving an entrie filesystem
such as /usr from one partition to another, etc.  Works slick.  It is also true
that the newer GNU tar offers the same functionality as well.  But, I've used
this so often, that I simply trust it implicitly.

Paul


  system structure standards.  I don't remember if it gave ownerships but
  it's worth a shot if someone knows what it's called and where I can find
  it.
 
 No, it's far too short to cover ownerships, only locations. The 1.2 FSS
 doesn't give it's own location(!), but only that of its FAQ which is
 ftp://tsx-11.mit.edu/pub/linux/docs/linux-standards/fsstnd/FSSTND-FAQ
 

I concur.  You're in for an install grin - I can smile cos I've bombed
my machines a few times.

 P.S. I don't see multiple copies of your postings here.

Nor do I.

Nathan

--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Copying a system (Was Re: Directory permissions.)

[Robert D. Hilliard]

On Tue, 29 Apr 1997 Nathan E Norman [EMAIL PROTECTED] wrote:

-snip--
 Using the correct tools is important.  David gives you one such tool - I
 personally type the following command in the directory I wish to copy:
 find . -print | cpio -p /target.  This is of course a simplification;
 find and cpio have a lot of powerful options, and people will argue the 
 merits of tar vs. cpio all day.  It works for me.  At any rate, mc is not
 up to the task.
-snip--

 I use a modification of this command that was once recommended on
one of the comp.os.linux.* newsgroups:
  find old_path -depth -print0|cpio -pdm0 new_path

 The '-m' option preserves file modification times, which is nice.
I don't know how important the other options are, but they work for me.
Similarly, I don't think the -depth option for find is needed, but I
still use it because that is what was recommended.

 If you copying an entire file system you would cd to root before
giving 'find .'.  If the file system is mounted du /proc returns zero,
since /proc is a pseudo file system that (I believe) references
various segments of the kernel image, but find/cpio copies at least
30 MB of the kernel image into /proc on the new system, which isn't
good.

 Another problem with issuing this command from a mounted
filesystem is that it will recursively copy /mnt (or whatever node the
system is being copied to), which will soon fill your disk.  If your
old system is on one partition, this can be prevented using the -mount
or -xdev options to find.

 To avoid copying some directories, such as /proc or /mnt, there
is a -prune option to find (you can't use -depth with -prune), but I
haven't been able to make it work.  Instead of using '.' for 'old
path', you can include each directory under / manually.  This is a
little tedious to type in, but works well.

 If you have a rescue partition the simplest system is to boot the
rescue partition, mount the old filesystem on one mount point and the
new file system on another mount point, and give the command:
  find old-mount-point -depth -print0|cpio -pdm0 new-mount-point
If the old file system is on several partitions, some creative
modifications are necessary.

Bob


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Copying a system (Was Re: Directory permissions.)

[Rick Jones]

The reason I opted for mc in the first place was for the ability to tag or
untag directories to avoid copying /proc and the /mnt directories.  Since
it had the option to retain UID's and GID's I thought it was a safe
option.  I backfired on me which I think is a bug and will report it as
such.

I will say that other than the directory permissions it worked well.  I
should have followed my usual procedure of dbl checking before I removed
the old file system.

The linuxconf suggestion changed some of the permissions for me.  The
system is working without any errors other than the smail error.

I think I should be able to operate without re-installing and fix the
permissions as I go.

Thanks to everyone for the helpful advice.

On Tue, 29 Apr 1997, Robert D. Hilliard wrote:

 On Tue, 29 Apr 1997 Nathan E Norman [EMAIL PROTECTED] wrote:
 
 -snip--
  Using the correct tools is important.  David gives you one such tool - I
  personally type the following command in the directory I wish to copy:
  find . -print | cpio -p /target.  This is of course a simplification;
  find and cpio have a lot of powerful options, and people will argue the 
  merits of tar vs. cpio all day.  It works for me.  At any rate, mc is not
  up to the task.
 -snip--
 
  I use a modification of this command that was once recommended on
 one of the comp.os.linux.* newsgroups:
   find old_path -depth -print0|cpio -pdm0 new_path
 
  The '-m' option preserves file modification times, which is nice.
 I don't know how important the other options are, but they work for me.
 Similarly, I don't think the -depth option for find is needed, but I
 still use it because that is what was recommended.
 
  If you copying an entire file system you would cd to root before
 giving 'find .'.  If the file system is mounted du /proc returns zero,
 since /proc is a pseudo file system that (I believe) references
 various segments of the kernel image, but find/cpio copies at least
 30 MB of the kernel image into /proc on the new system, which isn't
 good.
 
  Another problem with issuing this command from a mounted
 filesystem is that it will recursively copy /mnt (or whatever node the
 system is being copied to), which will soon fill your disk.  If your
 old system is on one partition, this can be prevented using the -mount
 or -xdev options to find.
 
  To avoid copying some directories, such as /proc or /mnt, there
 is a -prune option to find (you can't use -depth with -prune), but I
 haven't been able to make it work.  Instead of using '.' for 'old
 path', you can include each directory under / manually.  This is a
 little tedious to type in, but works well.
 
  If you have a rescue partition the simplest system is to boot the
 rescue partition, mount the old filesystem on one mount point and the
 new file system on another mount point, and give the command:
   find old-mount-point -depth -print0|cpio -pdm0 new-mount-point
 If the old file system is on several partitions, some creative
 modifications are necessary.
 
 Bob
 
 
 --
 TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
 [EMAIL PROTECTED] . 
 Trouble?  e-mail to [EMAIL PROTECTED] .
 
 

--Rick

[EMAIL PROTECTED]


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Copying a system (Was Re: Directory permissions.)

[Rob Browning]

Rick Jones [EMAIL PROTECTED] writes:

 The reason I opted for mc in the first place was for the ability to tag or
 untag directories to avoid copying /proc and the /mnt directories.  Since
 it had the option to retain UID's and GID's I thought it was a safe
 option.  I backfired on me which I think is a bug and will report it as
 such.

You could avoid proc and mnt like this:

# UNTESTED #
(cd /  \
 find `ls | egrep -v 'proc|mnt'` | \
 afio -o - (cd wherever  afio -i -))

This should move all directories from / to wherever, ignoring proc
and mnt and preserving all permissions.  You could also use find's
-prune option instead of the nested ls, and you could use find's
-mount option to avoid mounts like /mnt, or -fstype to avoid nfs or
other filesystems.

-- 
Rob


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Directory permissions.

[Rick Jones]

As some of you are aware, I recently transfered my file system from hda1
to hda2.  When I did it I used midnight commander.

MC has an option to keep UID's and GID's when copying.  Supprise! It only
does this on the files.  When it created the directories on hda2 it
made them ALL root.root using umask.

I discovered this when the following error appeared:

runq 04/29/1997 08:43:00: mailer error: cannot open 
/var/log/smail/paniclog: Permission denied

Which made me investigate the permissions.

There are two problems I'm addressing here.

1.  Is there an easy way to reset the permissions of my directories to
what they should be?  Such as a program that I can exicute that will set
them or go through and prompt me for the changes.

2.  The above error is actually related to the file permissions now since
I've changed it before.  It seems that cron did some kind of clean up this
morning and changed the permission back (on the files in this directory)
to what they were before.

Here is the directory after I changed permissions to add group write
permission to stop the error:

drwxrwxr-x   2 root mail 1024 Apr 29 06:43 .
drwxrwxr-x   7 root adm  1024 Apr 29 06:44 ..
-rw-rw-r--   1 root mail 3356 Apr 29 09:07 logfile
-rw-rw-r--   1 root mail   649572 Apr 29 06:56 logfile.0
-rw-rw-r--   1 root mail 5830 Apr 15 06:44 logfile.1.gz
-rw-rw-r--   1 root mail15244 Apr 13 06:44 logfile.2.gz
-rw-rw-r--   1 root mail13330 Apr 11 06:44 logfile.3.gz
-rw-rw-r--   1 root mail11078 Apr  8 06:43 logfile.4.gz
-rw-rw-r--   1 root mail 2453 Apr  5 06:43 logfile.5.gz
-rw-rw-r--   1 root mail11769 Apr  4 06:43 logfile.6.gz
-rw-rw-r--   1 root mail0 Apr 29 06:43 paniclog
-rw-rw-r--   1 root mail  750 Apr 29 06:43 paniclog.0
-rw-rw-r--   1 root mail   31 Apr 15 06:44 paniclog.1.gz
-rw-rw-r--   1 root mail   31 Apr 13 06:44 paniclog.2.gz
-rw-rw-r--   1 root mail   31 Apr 11 06:44 paniclog.3.gz
-rw-rw-r--   1 root mail   31 Apr  8 06:43 paniclog.4.gz
-rw-rw-r--   1 root mail   31 Apr  5 06:43 paniclog.5.gz
-rw-rw-r--   1 root mail   31 Apr  4 06:43 paniclog.6.gz

Why has this error started since the move from hda1?  I have been using
the file ownerships to set the directory ownerships since I know that mc
kept the file ownerships intact.

So now my system is half-hosed.  I assume there are other things not
working correctly even though I'm not getting any other errors and all
seems to be fine, so far.

I did this to avoid a full install when I repartitioned since I have no
backup system and have installed from ftp.  Somebody out there must have a
good way to reset my ownerships.

About a year ago I remember running across a doc that described the file
system structure standards.  I don't remember if it gave ownerships but
it's worth a shot if someone knows what it's called and where I can find
it.

I thought it might have been a HOW-TO but I just checked linux.org and
found none that looked like they described the file system structure.

I see a re-install in my future.  Can anybody give me a hand with this so
I don't have to resort to the obvious?

--Rick

[EMAIL PROTECTED]


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Directory permissions.

[David Wright]

On Tue, 29 Apr 1997, Rick Jones wrote:

 As some of you are aware, I recently transfered my file system from hda1
 to hda2.  When I did it I used midnight commander.
 
 MC has an option to keep UID's and GID's when copying.  Supprise! It only
 does this on the files.  When it created the directories on hda2 it
 made them ALL root.root using umask.
 [...]
 1.  Is there an easy way to reset the permissions of my directories to
 what they should be?  Such as a program that I can exicute that will set
 them or go through and prompt me for the changes.
 [...]
 So now my system is half-hosed.  I assume there are other things not
 working correctly even though I'm not getting any other errors and all
 seems to be fine, so far.
 
 I did this to avoid a full install when I repartitioned since I have no
 backup system and have installed from ftp.  Somebody out there must have a
 good way to reset my ownerships.

Well, the /easiest/ way might just be to copy the files in one of the
correct manners, overwriting both them and their ownerships. For example,
tar to stdout and pipe it to stdin of another tar with --save-permissions 
and --save-owners (done as root).

 About a year ago I remember running across a doc that described the file
 system structure standards.  I don't remember if it gave ownerships but
 it's worth a shot if someone knows what it's called and where I can find
 it.

No, it's far too short to cover ownerships, only locations. The 1.2 FSS
doesn't give it's own location(!), but only that of its FAQ which is
ftp://tsx-11.mit.edu/pub/linux/docs/linux-standards/fsstnd/FSSTND-FAQ

P.S. I don't see multiple copies of your postings here.
--
David Wright, Open University, Earth Science Department, Milton Keynes MK7 6AA
U.K.  email: [EMAIL PROTECTED]  tel: +44 1908 653 739  fax: +44 1908 655 151




--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Directory permissions.

[Nathan E Norman]

On Tue, 29 Apr 1997, David Wright wrote:

 On Tue, 29 Apr 1997, Rick Jones wrote:
 
  [ description of problem ]
  
  I did this to avoid a full install when I repartitioned since I have no
  backup system and have installed from ftp.  Somebody out there must have a
  good way to reset my ownerships.
 
 Well, the /easiest/ way might just be to copy the files in one of the
 correct manners, overwriting both them and their ownerships. For example,
 tar to stdout and pipe it to stdin of another tar with --save-permissions 
 and --save-owners (done as root).

Using the correct tools is important.  David gives you one such tool - I
personally type the following command in the directory I wish to copy:
find . -print | cpio -p /target.  This is of course a simplification;
find and cpio have a lot of powerful options, and people will argue the 
merits of tar vs. cpio all day.  It works for me.  At any rate, mc is not
up to the task.

 
  About a year ago I remember running across a doc that described the file
  system structure standards.  I don't remember if it gave ownerships but
  it's worth a shot if someone knows what it's called and where I can find
  it.
 
 No, it's far too short to cover ownerships, only locations. The 1.2 FSS
 doesn't give it's own location(!), but only that of its FAQ which is
 ftp://tsx-11.mit.edu/pub/linux/docs/linux-standards/fsstnd/FSSTND-FAQ
 

I concur.  You're in for an install grin - I can smile cos I've bombed
my machines a few times.

 P.S. I don't see multiple copies of your postings here.

Nor do I.

Nathan


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Directory permissions.

[Jim Pick]

Rick Jones wrote:

 1.  Is there an easy way to reset the permissions of my directories to
 what they should be?  Such as a program that I can exicute that will set
 them or go through and prompt me for the changes.

I'd suggest using the dpkgcert package by Klee Dienes - it scans
all of the files installed by packages and informs you of what files
have changed, and what files have different permissions/groups/owners.

I found it very useful and informative here.

I believe it is currently in experimental.  You will also need a
database of package certificates which contain the checksums.  Send
e-mail to Klee Dienes [EMAIL PROTECTED] to find out where to get these.

An alternative is do a dpkg -c on the original *.deb files to 
figure out the permissions.  Note that just reinstalling the
packages won't work, since dpkg -i doesn't replace old file
permissions with the new ones.

Cheers,

 - Jim

p.s.   I'm going to be out-of-range of the lists and my e-mail for
   a week -- I have to go to a clients site (a pulp mill in
   Nanaimo) -- ie. no 'net access -- arrgh




pgpEwR9an9TdH.pgp
Description: PGP signature

Re: Directory permissions.

[Christian Hudon]

On Apr 29, Nathan E Norman wrote
 
 On Tue, 29 Apr 1997, David Wright wrote:
 
  On Tue, 29 Apr 1997, Rick Jones wrote:
  
   [ description of problem ]
   
   I did this to avoid a full install when I repartitioned since I have no
   backup system and have installed from ftp.  Somebody out there must have a
   good way to reset my ownerships.
  
  Well, the /easiest/ way might just be to copy the files in one of the
  correct manners, overwriting both them and their ownerships. For example,
  tar to stdout and pipe it to stdin of another tar with --save-permissions 
  and --save-owners (done as root).
 
 Using the correct tools is important.  David gives you one such tool - I
 personally type the following command in the directory I wish to copy:
 find . -print | cpio -p /target.  This is of course a simplification;
 find and cpio have a lot of powerful options, and people will argue the 
 merits of tar vs. cpio all day.  It works for me.  At any rate, mc is not
 up to the task.

Or, since Debian has GNU cp, I simply use cp -a. It preserves
everything. (The 'a' stands for archive.)

You might want this as a bug report against mc, though. If it said
'preserve' in the menu, IMHO it should preserve both files and
directories's permissions.

  Christian


pgpotaGkykCH7.pgp
Description: PGP signature