Hello all: I am trying to set up jetico's bestcrypt on my SUSE 10.0 x86_64. Bestcrypt startup script (/etc/init.d/bcrypt start) creates the bcrypt[0-16] devices in /dev/. The permissions of those files should be 0666 but they are: brw-r----- 1 root disk 188, 0 2005-11-29 22:07 /dev/bcrypt0 I created an udev rule file: /etc/udev/rules.d/10-local.rules that contains: KERNEL=="bcrypt[0-9]*", NAME="%k", MODE="0666" I restarted udev with udevstart but the permissions have not changed, the udev rule did not work. I do't know how could I make this rule work. Any help is appreciated. Thanks, IG __________________________________________________________________________ KÖTELEZŐ és mégis kényelmes! Csak november 30-ig, az [origo] Biztosításon! http://origo.hu/biztositas
Istvan Gabor wrote:
Hello all:
I am trying to set up jetico's bestcrypt on my SUSE 10.0 x86_64. Bestcrypt startup script (/etc/init.d/bcrypt start) creates the bcrypt[0-16] devices in /dev/. The permissions of those files should be 0666 but they are: brw-r----- 1 root disk 188, 0 2005-11-29 22:07 /dev/bcrypt0
I created an udev rule file: /etc/udev/rules.d/10-local.rules that contains: KERNEL=="bcrypt[0-9]*", NAME="%k", MODE="0666" I restarted udev with udevstart but the permissions have not changed, the udev rule did not work.
If the startup script is creating them then udev is out of the picture as long as udev has run before bestcrypt. The permissions/owner must be set in the bestcrypt startup script. No need to create any udev rule if the startup script is creating the device entries. Mark
If the startup script is creating them then udev is out of the picture as long as udev has run before bestcrypt. The permissions/ owner must be set in the bestcrypt startup script. No need to create any udev rule if the startup script is creating the device entries.
Mark
Thanks. But see the bcrypt start script: [snip] MAJOR=188 MINOR=0 case "$1" in start) echo "Initializing BestCrypt." rm -rf /dev/bcrypt?* 2>/dev/null for (( x=0 ; x<16 ; x++)) ; do mknod -m 666 /dev/bcrypt$x b $MAJOR $(( MINOR+x )) ; done [snip} According to this the permissions should be 666, not 644 as they are. How can I get then the right permissions? Thanks, IG __________________________________________________________________________ KÖTELEZŐ és mégis kényelmes! Csak november 30-ig, az [origo] Biztosításon! http://origo.hu/biztositas
Istvan Gabor wrote:
If the startup script is creating them then udev is out of the picture as long as udev has run before bestcrypt. The permissions/ owner must be set in the bestcrypt startup script. No need to create any udev rule if the startup script is creating the device entries.
Mark
Thanks. But see the bcrypt start script:
[snip] MAJOR=188 MINOR=0
case "$1" in start) echo "Initializing BestCrypt." rm -rf /dev/bcrypt?* 2>/dev/null for (( x=0 ; x<16 ; x++)) ; mknod -m 666 /dev/bcrypt$x b $MAJOR $(( MINOR+x )) ; done [snip}
According to this the permissions should be 666, not 644 as they are. How can I get then the right permissions?
Are you are saying that after you boot the machine and start the service manually, (/etc/init.d/bestcrypt start) the permissions are wrong? I suspect they are correct and it only happens incorrectly when you boot the machine and let the service start normally. If that is the case then the service probably needs to start later. When does the bestcrypt service script start? If the permissions are not 666 after manually starting the script, what happens when you really do it manually? Try one of the 16 and see: rm /dev/bcrypt0 mknod -m 666 /dev/bcrypt0 b 188 0 ls -al dev/bcrypt0 Or, is the startup script maybe changing the mode later after creating them? Mark
Are you are saying that after you boot the machine and start the service manually, (/etc/init.d/bestcrypt start) the permissions are wrong? No. If I start the script manually in a terminal the devices get the right permissions. (But it really inconvenient to run the script manually after every bootup.)
I suspect they are correct and it only happens incorrectly when you boot the machine and let the service start normally. This is exactly what happens.
If that is the case then the service probably needs to start later. When does the bestcrypt service script start? I don't know how I can check this. Here is my rc5.d list (only starting processes), bcrypt is S09:
S01earlysyslog S01fbset S01random S02earlykbd S03dbus S03resmgr S04boot.udev S04earlykdm S05network S06syslog S08mdnsd S08portmap S08splash_early S09bcrypt S10nfs S10nfsboot S12acpid S12alsasound S12cups S12kbd S12microcode S12running-kernel S12smpppd S12splash S12sshd S13xdm S14nscd S14postfix S14smbfs S15cron S16haldaemon S17powersaved S18cupsrenice S21SuSEfirewall2_setup
Mark
Thanks, IG __________________________________________________________________________ KÖTELEZŐ és mégis kényelmes! Csak november 30-ig, az [origo] Biztosításon! http://origo.hu/biztositas
On Wed, 2005-11-30 at 21:48 +0100, Istvan Gabor wrote:
Are you are saying that after you boot the machine and start the service manually, (/etc/init.d/bestcrypt start) the permissions are wrong? No. If I start the script manually in a terminal the devices get the right permissions. (But it really inconvenient to run the script manually after every bootup.)
I suspect they are correct and it only happens incorrectly when you boot the machine and let the service start normally. This is exactly what happens.
If that is the case then the service probably needs to start later. When does the bestcrypt service script start? I don't know how I can check this. Here is my rc5.d list (only starting processes), bcrypt is S09:
Look at the Requires: line in the script as this will determine when it is run. If you need to start it later currently starts us a Requires: item from a later running script (one of the higher numbered scripts). -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998
participants (3)
-
Istvan Gabor -
Ken Schneider -
Mark Hounschell