Re: File and directory permissions

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.

Re: File and directory permissions

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

Re: File and directory permissions

-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

Re: File and directory permissions

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?

Re: File and directory permissions

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

Re: File and directory permissions

-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

Re: File and directory permissions

-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":

Re: File and directory permissions

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

Re: File and directory permissions

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: >

Re: File and directory permissions

-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

Re: File and directory permissions

-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

Re: File and directory permissions

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

Re: File and directory permissions

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

Re: File and directory permissions

-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

Re: File and directory permissions

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

Re: File and directory permissions

-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

Re: File and directory permissions

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

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

File and directory permissions

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

Changes in the way tar(1) constructs directory permissions

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/

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

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

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

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

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

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.

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

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

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

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

[Fwd: Debian Network Installation Insecure Default Directory Permissions]

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

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

Re: Directory Permissions

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

Re: Directory Permissions

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

Re: Directory Permissions

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

Re: file and directory permissions question...

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

Re: file and directory permissions question...

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,

file and directory permissions question...

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,

httpd user and user directory permissions dilemna

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

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

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

Re: Directory permissions

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

Re: Directory permissions

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

Directory permissions

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

Re: Directory permissions

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] : :'

Re: Directory permissions

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

Re: Directory permissions

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 *

Re: Directory permissions

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

Re: Directory permissions

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

Re: Directory permissions

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

Re: Directory permissions

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,

home directory permissions

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

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

Re: home directory permissions

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?

Re: home directory permissions

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

Re: home directory permissions

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

Re: home directory permissions

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.

Re: home directory permissions

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

Re: Correct directory permissions list?

[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

Correct directory permissions list?

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

Re: Directory permissions.

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,

Copying a system (Was Re: Directory permissions.)

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 |

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

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

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

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

Directory permissions.

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

Re: Directory permissions.

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

Re: Directory permissions.

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

Re: Directory permissions.

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

Re: Directory permissions.

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