Re: Linux permissions and which(1)
On Fri, Sep 05, 2003 at 01:55:35PM -0700, Bill Moseley wrote: See it again... [EMAIL PROTECTED]:~/which-2.14$ which foo /usr/bin/foo [EMAIL PROTECTED]:~/which-2.14$ bash -c foo foo in /usr/bin [EMAIL PROTECTED]:~/which-2.14$ foo bash: /usr/local/bin/foo: Permission denied Ah, that's probably because bash is caching a previous lookup of the file. -- Bill Moseley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux permissions and which(1)
Bill Moseley wrote: On Thu, Sep 04, 2003 at 09:45:53PM -0700, Bill Moseley wrote: I was looking at the source code to the which(1) command (apt-get source which = which-2.14 ). Just to add, the which(1) command installed on my Debian system is working correctly -- but only when I build which(1) from the source package: Filename: pool/main/w/which/which_2.14-4_i386.deb I just want to be clear that I'm understanding Linux perms correctly. Wow, when I read your first post I thought 'his shell is messed up or something, that cant be right...'. So I tested it. Then I tested it with csh and ksh. http://www.seas.rochester.edu:8080/CNG/docs/Security/node11.html If that is correct, (it makes a lot of sense) then I think I'm going to blame my misconception on 1) VMS as my first multi-user OS experiance and their 'world' flag and 2) lots of bad documentation. I probably ought to blame it on myself for not proving to myself what all the different file permissions do. Out of habit (and not correct knowledge) I've given user execute when I give it to group or other, and group execute when I give it to other. File permissions: -r--r--r-x whoami = jacob groups = jacob audio user.group jacob.jacob ./t = sh: permission denied root.jacob ./t = sh: permission denied root.root ./t = Hello world So, either everything else is wrong, or the author of which had made an assumption about other being 'world' like I had made. Jacob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux permissions and which(1)
On Thu, Sep 04, 2003 at 10:03:52PM -0700, Bill Moseley wrote: On Thu, Sep 04, 2003 at 09:45:53PM -0700, Bill Moseley wrote: I was looking at the source code to the which(1) command (apt-get source which = which-2.14 ). Just to add, the which(1) command installed on my Debian system is working correctly -- but only when I build which(1) from the source package: Filename: pool/main/w/which/which_2.14-4_i386.deb In case you don't know, the default which(1) on Debian systems comes from the debianutils package, not which. The which package is a bloated not-invented-here thing; I have no idea why it exists. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux permissions and which(1)
Colin Watson [EMAIL PROTECTED] [2003:09:05:09:53:35+0100] scribed: On Thu, Sep 04, 2003 at 10:03:52PM -0700, Bill Moseley wrote: On Thu, Sep 04, 2003 at 09:45:53PM -0700, Bill Moseley wrote: I was looking at the source code to the which(1) command (apt-get source which = which-2.14 ). Just to add, the which(1) command installed on my Debian system is working correctly -- but only when I build which(1) from the source package: Filename: pool/main/w/which/which_2.14-4_i386.deb In case you don't know, the default which(1) on Debian systems comes from the debianutils package, not which. The which package is a bloated not-invented-here thing; I have no idea why it exists. OK, but what is the _correct_ behaviour, and where is it documented? -- Best Regards, mds mds resource 877.596.8237 - Dare to fix things before they break . . . - Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . -- pgp0.pgp Description: PGP signature
Re: Linux permissions and which(1)
On Fri, Sep 05, 2003 at 10:32:48AM -0500, Michael D Schleif wrote: Colin Watson [EMAIL PROTECTED] [2003:09:05:09:53:35+0100] scribed: On Thu, Sep 04, 2003 at 10:03:52PM -0700, Bill Moseley wrote: On Thu, Sep 04, 2003 at 09:45:53PM -0700, Bill Moseley wrote: I was looking at the source code to the which(1) command (apt-get source which = which-2.14 ). Just to add, the which(1) command installed on my Debian system is working correctly -- but only when I build which(1) from the source package: Filename: pool/main/w/which/which_2.14-4_i386.deb In case you don't know, the default which(1) on Debian systems comes from the debianutils package, not which. The which package is a bloated not-invented-here thing; I have no idea why it exists. OK, but what is the _correct_ behaviour, and where is it documented? The correct behaviour can be deduced easily from which(1): which returns the pathnames of the files which would be exe- cuted in the current environment, had its arguments been given as commands in a strictly POSIX-conformant shell. http://www.opengroup.org/onlinepubs/007904975/utilities/xcu_chap02.html#tag_02_09_01_01 is probably the specification you want. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux permissions and which(1)
On Fri, Sep 05, 2003 at 05:17:26PM +0100, Colin Watson wrote: OK, but what is the _correct_ behaviour, and where is it documented? The correct behaviour can be deduced easily from which(1): which returns the pathnames of the files which would be exe- cuted in the current environment, had its arguments been given as commands in a strictly POSIX-conformant shell. which is true unless you are using the wrong which, which I was doing because I simply did a apt-get source which... Here's something interesting. Two foo programs: [EMAIL PROTECTED]:~/which-2.14$ ls -l /usr/local/bin/foo /usr/bin/foo -rwxr-xr-x1 moseley audio 34 2003-09-05 13:27 /usr/bin/foo -rwxr-xr-x1 moseley audio 40 2003-09-05 13:27 /usr/local/bin/foo [EMAIL PROTECTED]:~/which-2.14$ /usr/bin/foo foo in /usr/bin [EMAIL PROTECTED]:~/which-2.14$ /usr/local/bin/foo foo in /usr/local/bin [EMAIL PROTECTED]:~/which-2.14$ which foo /usr/local/bin/foo Now turn of execute for the owner (me): bumby:~# chmod 655 /usr/local/bin/foo Here's the interesting part. [EMAIL PROTECTED]:~/which-2.14$ foo bash: /usr/local/bin/foo: /bin/sh: bad interpreter: Permission denied Still finds the first matching file in the path, but then permission denied when trying to run it. [remember this one for below -- still at 644 perms on /usr/local/bin/foo] [EMAIL PROTECTED]:~/which-2.14$ bash -c foo bash: /usr/local/bin/foo: /bin/sh: bad interpreter: Permission denied [EMAIL PROTECTED]:~/which-2.14$ which foo /usr/bin/foo Hum, but which(1) skips over the one in /usr/local/bin because of owner permissions (true, I can't run that one), but the shell doesn't. Now looking at the broken which(1) program -- different from the which(1) that comes with binutils: [EMAIL PROTECTED]:~/which-2.14$ ./which foo /usr/local/bin/foo That version is broken because of what I posted yesterday: that version is seeing that I don't have *owner* permissions and moving on to group and other perms which I do have permissions for. Now remove all permissions to execute: bumby:~# chmod 644 /usr/local/bin/foo [EMAIL PROTECTED]:~/which-2.14$ ./which foo /usr/bin/foo So now since I don't have ANY permissions which-2.14 moves on. But the binutils which(1) still points to the one in /usr/bin: [EMAIL PROTECTED]:~/which-2.14$ which foo /usr/bin/foo Now the fun starts: [EMAIL PROTECTED]:~/which-2.14$ foo bash: /usr/local/bin/foo: Permission denied Remember this from above? [EMAIL PROTECTED]:~/which-2.14$ bash -c foo foo in /usr/bin Now what's happening there? See it again... [EMAIL PROTECTED]:~/which-2.14$ which foo /usr/bin/foo [EMAIL PROTECTED]:~/which-2.14$ bash -c foo foo in /usr/bin [EMAIL PROTECTED]:~/which-2.14$ foo bash: /usr/local/bin/foo: Permission denied [EMAIL PROTECTED]:~/which-2.14$ ls -l /usr/local/bin/foo -rw-r--r--1 moseley audio 40 2003-09-05 13:27 /usr/local/bin/foo -- Bill Moseley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux permissions and which(1)
On Thu, Sep 04, 2003 at 09:45:53PM -0700, Bill Moseley wrote: I was looking at the source code to the which(1) command (apt-get source which = which-2.14 ). Just to add, the which(1) command installed on my Debian system is working correctly -- but only when I build which(1) from the source package: Filename: pool/main/w/which/which_2.14-4_i386.deb I just want to be clear that I'm understanding Linux perms correctly. -- Bill Moseley [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux permissions and which(1)
Bill Moseley wrote: I was looking at the source code to the which(1) command (apt-get source which = which-2.14 ). As you might imagine, which(1) prepends the path to a name, checks if it exists and then checks if it's executable by the current process (your uid). In the which package is a file bash.c that contains the following code. At this point the file has been found and now it's just checking permissions. /* If we are the owner of the file, the owner execute bit applies. */ if (user_id == finfo.st_uid X_BIT (u_mode_bits (finfo.st_mode))) return (FS_EXISTS | FS_EXECABLE); /* If we are in the owning group, the group permissions apply. */ if (group_member (finfo.st_gid) X_BIT (g_mode_bits (finfo.st_mode))) return (FS_EXISTS | FS_EXECABLE); /* If `others' have execute permission to the file, then so do we, since we are also `others'. */ if (X_BIT (o_mode_bits (finfo.st_mode))) return (FS_EXISTS | FS_EXECABLE); else return (FS_EXISTS); This seems wrong, if I understand Linux permissions correctly. If you are the *owner* of a file, then it's the *owner* permissions that count. If the owner perms say you can't read it then it doesn't matter what the group and other perms are. In that code above if you are the owner but don't have execute perms then it moves onto checking the group perms, and then other perms. Am I crazy is is that code wrong? After some simple tests, it seems wrong. -rw-r-xr-- and -rw-r--r-x aren't executable while -rwxr--r-- *is*. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
