Does anybody know of a KSH command or some code that I can call that
checks read, write, execute permissions on a directory for a particular
user without having to login and actually doing the above-mentioned
actions.

For example I am looking for something like this, which will return a
TRUE or FALSE

IsGroupReadable("directory name", "group name")
IsUserWriteable("directory name", "user name")
IsUserExecutable("directory name", user name")

Thanks in advance to all who reply

2006-11-3, 06:50(-08), Stu:
> Does anybody know of a KSH command or some code that I can call that
> checks read, write, execute permissions on a directory for a particular
> user without having to login and actually doing the above-mentioned
> actions.
>
> For example I am looking for something like this, which will return a
> TRUE or FALSE
>
> IsGroupReadable("directory name", "group name")
> IsUserWriteable("directory name", "user name")
> IsUserExecutable("directory name", user name")
>
> Thanks in advance to all who reply

Those are wrong questions. Even if we forget about the ACLs:

Within a same group, different users may have different rights
to a file. And a user may or may not be able to access a same
file depending on the list of groups he is curently in.

So, you want:

isReadable(file, user, groupe1, groupe2, ...);
isWritable(file, user, groupe1, groupe2, ...);
....

Then you can do:

isReadable() {
# args: <file>, <uid>, <colon-separated-list-of-gids>
(
set -f
IFS=" "
uid=$2 gids=$3
set -- $(ls -lnd -- "$1")
if [ "$uid" -eq 0 ]; then
case $1 in
(?-??-??-*) return 1;;
esac
return 0
fi
if [ "$3" -eq "$uid" ]; then
case $1 in
(?r*) return 0;
esac
return 1
fi
case :$gids: in
(*:"$4":*)
case $1 in
(????r*) return 0;;
esac
return 1
;;
esac
case $1 in
(???????r*) return 0;;
esac
return 1
)
}

--
Stéphane

Thanks so far it seems to work okay but I will contibue to test for the
writeable function can I change the "r" to "w"?





Stephane CHAZELAS wrote:
> 2006-11-3, 06:50(-08), Stu:
> > Does anybody know of a KSH command or some code that I can call that
> > checks read, write, execute permissions on a directory for a particular
> > user without having to login and actually doing the above-mentioned
> > actions.
> >
> > For example I am looking for something like this, which will return a
> > TRUE or FALSE
> >
> > IsGroupReadable("directory name", "group name")
> > IsUserWriteable("directory name", "user name")
> > IsUserExecutable("directory name", user name")
> >
> > Thanks in advance to all who reply
>
> Those are wrong questions. Even if we forget about the ACLs:
>
> Within a same group, different users may have different rights
> to a file. And a user may or may not be able to access a same
> file depending on the list of groups he is curently in.
>
> So, you want:
>
> isReadable(file, user, groupe1, groupe2, ...);
> isWritable(file, user, groupe1, groupe2, ...);
> ...
>
> Then you can do:
>
> isReadable() {
> # args: <file>, <uid>, <colon-separated-list-of-gids>
> (
> set -f
> IFS=" "
> uid=$2 gids=$3
> set -- $(ls -lnd -- "$1")
> if [ "$uid" -eq 0 ]; then
> case $1 in
> (?-??-??-*) return 1;;
> esac
> return 0
> fi
> if [ "$3" -eq "$uid" ]; then
> case $1 in
> (?r*) return 0;
> esac
> return 1
> fi
> case :$gids: in
> (*:"$4":*)
> case $1 in
> (????r*) return 0;;
> esac
> return 1
> ;;
> esac
> case $1 in
> (???????r*) return 0;;
> esac
> return 1
> )
> }
>
> --
> Stéphane

2006-11-3, 07:34(-08), Stu:
> Thanks so far it seems to work okay but I will contibue to test for the
> writeable function can I change the "r" to "w"?
[...]

You also want to check the position

$1 will be the first field returned by ls -lnd, looking like

drwxrwxrwx were any of the rwx may be replaced with "-"
indicating no permission.

So instead of (?r*), you want (??w*)
instead of (????r*), you want (?????w*)
instead of (???????r*), you want (????????w*)

Beware that for "x", it's more complicated, as you may have a s,
S, t or T instead. See ls or chmod man page for details.

--
Stéphane

2006-11-03 <slrnekmqoq.9pf.stephane.chazelas@spam.is.invalid> ,
Stephane CHAZELAS wrote:
> Beware that for "x", it's more complicated, as you may have a s,
> S, t or T instead. See ls or chmod man page for details.

To check x, you'd use ???[xs]* ??????[xs]* ?????????[xt]* - capital
S and T means the sticky/setid bit is set and the execute bit is not.

2006-11-3, 17:33(+00), Jordan Abel:
> 2006-11-03 <slrnekmqoq.9pf.stephane.chazelas@spam.is.invalid> ,
> Stephane CHAZELAS wrote:
>> Beware that for "x", it's more complicated, as you may have a s,
>> S, t or T instead. See ls or chmod man page for details.
>
> To check x, you'd use ???[xs]* ??????[xs]* ?????????[xt]* - capital
> S and T means the sticky/setid bit is set and the execute bit is not.

And the part for root changed to:

if [ "$uid" -eq 0 ]; then
case $1 in
(???[!xs]??[!xs]??[!xt]*) return 1;;
esac
return 0
fi


--
Stéphane

Stephane CHAZELAS <this.address@is.invalid> wrote, on Fri, 03 Nov 2006:

> So instead of (?r*), you want (??w*)
> instead of (????r*), you want (?????w*)
> instead of (???????r*), you want (????????w*)
>
> Beware that for "x", it's more complicated, as you may have a s,
> S, t or T instead. See ls or chmod man page for details.

POSIX allows other letters as well:

"Implementations may add other characters to this list for the
third character position. Such additions shall, however, be
written in lowercase if the file is executable or searchable, and
in uppercase if it is not."

The only example I am familiar with is that on systems which support
mandatory locking the group execute position is "L" if locking is
enabled for the file. But to allow for future extensions, you
should take [a-z] to mean execute permission and [A-Z] to mean no
execute permission (for POSIX-conforming versions of ls).

Beware that some older versions of ls (e.g. /bin/ls on Solaris)
use lowercase "l" instead of uppercase "L" for mandatory locking,
which makes it more difficult to write a script that caters for
non-POSIX versions of ls as well.

--
Geoff Clare <netnews@gclare.org.uk>

Geoff Clare wrote:

> [special characters in permission bits] on systems which support
> mandatory locking the group execute position is "L" if locking is
> enabled for the file.

> Beware that some older versions of ls (e.g. /bin/ls on Solaris)
> use lowercase "l" instead of uppercase "L" for mandatory locking,

even more variety on Solaris 9:
xpg4-ls: L, bin-ls: l, ucb- and GNU-4.1-ls: S


I had not bothered about these variations until now,
But out of curiosity i once collected various meanings and
implementations of permission bits themselves, apart from
read/write/execute. Does anybody know more examples?

1. Files

set gid:

* [SVID3 , SunOS 4, 5, HP-UX 9] on not group-executables:
Candidate for mandatory file locking in connection with fcntl().
See also "available implementations" in Mandatory File Locking
for Linux (src/linux/mandatory.txt, '96).

sticky bit:

* the well known meaning for executables,
<sys/stat.h> on V7: "S_ISVTX: save text image after execution"

a) [V7, SysIII, 4.3BSD-Reno] Only changeable by privileged user.
Usually not implemented anymore after 4.3BSD-Reno and probably
after System III due to then improved virtual memory management.
Interestingly, many later systems still document it, e.g.,
SunOS 5: sticky(5), OpenBSD 2.9: sticky(8), HP-UX 11: chmod(2).

b) [HP-UX 11] all ex/vi hardlinks have this bit set.
Apparently, this bit is still used for local paging of
executables located on an NFS. See the HP-UX FAQ.

c) [IRIX 6.5.10] ex still has this bit set.

other meanings of the sticky bit:

* [HP-UX 11] on symbolic links:
transition links are created with the almost undocumented lchmod(2).
Purpose: to ease transition to new SVR4 FS layout. See the HP-UX FAQ.

* [IRIX 6.5.10] on dynamic loader for elf executables:
The read only address space of the old process is made available to
the loader in the new process (considerable speed-up possible)

* [SunOS 3 (and 4?)] on regular, non-executable files:
system page cache is not used; for example for swap files of diskless
clients, so that swapping doesn't flush more valuable data in the page
cache. Still documented on SunOS 5, sticky(5).

2. Directories

set uid:

* [HP-UX 9] to create context dependent files, "S_CDF" for chmod(2):
Implemented with a hidden directory containing the actual, respective
entries for different unix nodes. The filenames have the nodename
as suffix. See also cdf(4), context(5).
* [FreeBSD X] (user-)ownership of new directory entries.
Used to "reduce support calls for file servers".
Optionally available with the "kernel option "SUIDDIR".

set gid:

* well known meaning (group-)ownership of new directory entries:
New entries will have the same group id like the directory.
Introduced with BSD.

sticky bit:

* [SVID4] well known appliance in /tmp:
directory entries can only be removed if the user owns the
entry or the directory or if the file is writable for him.

Sven Mascheck <cus.p.mascheck@spamgourmet.com> wrote, on Tue, 07 Nov 2006:

> 2. Directories
[snip]

> sticky bit:
>
> * [SVID4] well known appliance in /tmp:
> directory entries can only be removed if the user owns the
> entry or the directory or if the file is writable for him.

Are you sure that's what SVID4 says? It doesn't match the SUSv3
requirements. This is from XBD6 4.2 Directory Protection:

If a directory is writable and the mode bit S_ISVTX is set on the
directory, a process may remove or rename files within that directory
only if one or more of the following is true:

* The effective user ID of the process is the same as that of the
owner ID of the file.

* The effective user ID of the process is the same as that of the
owner ID of the directory.

* The process has appropriate privileges.

and this from the unlink() ERRORS section:

[EPERM] or [EACCES]
The S_ISVTX flag is set on the directory containing the file
referred to by the path argument and the caller is not the file
owner, nor is the caller the directory owner, nor does the caller
have appropriate privileges.

--
Geoff Clare <netnews@gclare.org.uk>

In article <eioer1UqhcL1@news.in-ulm.de>,
Sven Mascheck <cus.p.mascheck@spamgourmet.com> wrote:
>But out of curiosity i once collected various meanings and
>implementations of permission bits themselves, apart from
>read/write/execute. Does anybody know more examples?
....
>2. Directories
>
>set uid:

SCO OpenServer 5: On HTFS filesystems with file versioning ("undelete")
enabled, the setuid bit on a directory determines whether file versioning is
enabled for that particular directory. If it is, files in that directory that
are removed or opened with O_TRUNC are actually moved to a versioned name, and
versioned names are hidden from the view given by readdir(). Newly created
directories inherit setuid from parent directories.

John
--
John DuBois spcecdt@armory.com KC6QKZ/AE http://www.armory.com/~spcecdt/

Geoff Clare wrote:

> Are you sure that's what SVID4 says?

No, unfortunately i even don't have the SVID4 available
and just have reused the simplified wording. (Even worse:
Solaris chmod(2) most probably is SVID4-like and reads
like your quote.)

Geoff Clare wrote:

> Are you sure that's what SVID4 says?

No, unfortunately i even don't have the SVID4 available
and just have reused the simplified wording.
Solaris chmod(2) might be SVID4-like and reads more
complete, like your quote, but only mentions "user"
and not the uid/euid issue.

[confusion-supersede]