Sponsored Content
Special Forums Cybersecurity Attacking Potential of sh-scripts Post 302509527 by hergp on Thursday 31st of March 2011 02:40:12 AM
Old 03-31-2011
Kornshell 93 has a long list of commands built into the shell for performance reasons. So if you execute chmod in ksh93, you don't need the external chmod program. Sometimes you need to call chmod with a full pathname, but that is not much of an obstacle.

Code:
$ type chmod
chmod is a tracked alias for /usr/bin/chmod
$ type /usr/ast/bin/chmod
/usr/ast/bin/chmod is a shell builtin

(from Opensolaris' ksh)

I don't think, chroot will help you much in this case. The only solution I can think of, is to delete ksh93 or compile your own version without builtins - which will result in slower execution of shellscripts.
This User Gave Thanks to hergp For This Post:
 

3 More Discussions You Might Find Interesting

1. UNIX for Dummies Questions & Answers

Potential new user of Unix

Hi all, Complete and utter virgin Unix person here (I don't even have the OS yet) As I'm doing a "looking into it" kinda thing before I move from MS I hope my questions are not inappropriate. 1. Should I get some kind off anti virus software. I know Unix is pretty good for not getting them... (2 Replies)
Discussion started by: dhula
2 Replies

2. AIX

how to handle potential file contention

I need to change how a posting procedure currently works in order to improve load balancing but I am hitting a potential file contention problem that I was wondering if someone here could assist me with... In a directory called FilePool I would have a bunch of files that are constantly coming in... (3 Replies)
Discussion started by: philplasma
3 Replies

3. HP-UX

Potential file system contention on directory

We have an 8-processor Itanium system running HP-UX 11.23 connected to shared SAN discs. We have an application that creates files (about 10) in a specific directory. When the application terminates, these files are removed (unlink) and a few others are updated. The directory contains... (8 Replies)
Discussion started by: FDesrochers
8 Replies
setkey(3C)						   Standard C Library Functions 						setkey(3C)

NAME
setkey - set encoding key SYNOPSIS
#include <stdlib.h> void setkey(const char *key); DESCRIPTION
The setkey() function provides (rather primitive) access to the hashing algorithm employed by the crypt(3C) function. The argument of setkey() is an array of length 64 bytes containing only the bytes with numerical value of 0 and 1. If this string is divided into groups of 8, the low-order bit in each group is ignored; this gives a 56-bit key which is used by the algorithm. This is the key that will be used with the algorithm to encode a string block passed to encrypt(3C). RETURN VALUES
No values are returned. ERRORS
The setkey() function will fail if: ENOSYS The functionality is not supported on this implementation. USAGE
In some environments, decoding may not be implemented. This is related to U.S. Government restrictions on encryption and decryption rou- tines: the DES decryption algorithm cannot be exported outside the U.S.A. Historical practice has been to ship a different version of the encryption library without the decryption feature in the routines supplied. Thus the exported version of encrypt() does encoding but not decoding. Because setkey() does not return a value, applications wishing to check for errors should set errno to 0, call setkey(), then test errno and, if it is non-zero, assume an error has occurred. ATTRIBUTES
See attributes(5) for descriptions of the following attributes: +-----------------------------+-----------------------------+ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | +-----------------------------+-----------------------------+ |Interface Stability |Standard | +-----------------------------+-----------------------------+ |MT-Level |Safe | +-----------------------------+-----------------------------+ SEE ALSO
crypt(3C), encrypt(3C), attributes(5), standards(5) SunOS 5.10 14 Aug 2002 setkey(3C)
All times are GMT -4. The time now is 12:21 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy