how can I get virtuoso to preserve ownership and permission

F

fogh

Guest
Hi All,

When I edit and then save a schematic that belongs to johndoe, it ends up
owned by me and having my umask as permissions.

Is there a way to alter this behavior and get the "save" to do just this
(save) and no fooling around with ownership/permissions ?

(sorry if this is an old topic. I did not find it on dejanews.)
 
jayl-news@accelerant.net wrote:
fogh wrote:

When I edit and then save a schematic that belongs to johndoe, it

ends up

owned by me and having my umask as permissions.

Is there a way to alter this behavior and get the "save" to do just

this

(save) and no fooling around with ownership/permissions ?


I don't know if there's any significant difference between OA and cdb
in this regard.

I believe the Virtuoso drill for saving .cdb is essentially:

0) unlink .cd%
1) mv .cdb .cd% (via rename(2) or the equiv)
2) create & write a new .cdb

I'd be reluctant to change this even if I could, because
it is robust in a file-system-full scenario (except in a
really bizarre circumstance, the rename will succeed and you'll
still have a backup file even if the file system is truly 100%
and the new write fails).

In general, you won't have permission to chown the new
.cdb.
I don t understand why. Since the new cdb belongs to me (the SKILL
trigger job owner), I should be able to change permission to the same as
cd% and then give ownership to owner of cd% ?
Am I missing something ?

In principle, you could set a post-save callback to:

1) mv the new .cdb to .cdbnew
2) mv the old .cd% back to .cdb (owner/permission preserved).
3) copy the old .cdb to .cd%, set the mtime in .cd%
to match the old .cdb (lose the owner, but you can't
help that).
3) write the the contents of .cdbnew back over the old .cdb
(hence inheriting the old owner/permissions).
4) unlink .cdbnew

SKILL gives you renameFile(), so you can almost do this in
SKILL; but no way I know of to set mtime from generic SKILL.
Jay,
thank for the detailed tips !
 
fogh wrote:
jayl-news@accelerant.net wrote:
In general, you won't have permission to chown the new
.cdb.

I don t understand why. Since the new cdb belongs to me (the SKILL
trigger job owner), I should be able to change permission to the same as
cd% and then give ownership to owner of cd% ?
Am I missing something ?
chown is a priviledged (root) operation.

With some of the new caps models out there, it's possible (but a major
security risk) to grant this to normal users (CAP_CHOWN on SELinux, for
example).

--
David Cuthbert dacut at cadence dot com
Cadence Design Systems +1 (412) 599-1820
 
fogh wrote:
I never even noticed. I have been using chown to give away files as
normal user to other normal users on HPUX11i , solaris8 and redhat7.3
for years without noticing.
(But it seems to be the default on solaris8 tho.) What other
OS/security settings have this restriction by default ? What security
risk does it pose ?
chown or chmod? I'm fairly sure that it's not enabled on RedHat or
Solaris...

The immediate security risk that comes to mind:
chmod 4755 some_destructive_script.sh
chown user some_destructive_script.sh
/bin/sh some_destructive_script.sh

And you're now running that script as that user.

--
David Cuthbert dacut at cadence dot com
Cadence Design Systems +1 (412) 599-1820
 
David Cuthbert wrote:
fogh wrote:

I never even noticed. I have been using chown to give away files as
normal user to other normal users on HPUX11i , solaris8 and redhat7.3
for years without noticing.
(But it seems to be the default on solaris8 tho.) What other
OS/security settings have this restriction by default ? What security
risk does it pose ?


chown or chmod? I'm fairly sure that it's not enabled on RedHat or
Solaris...
chown.
Yes, I typoed my previous post. I could see that chown is _not_ allowed
by default in solaris8.

The immediate security risk that comes to mind:
chmod 4755 some_destructive_script.sh
chown user some_destructive_script.sh
/bin/sh some_destructive_script.sh

And you're now running that script as that user.
I tried this on linux, on a local filesystem. Indeed it is disabled by
default there too. I did not use the LIDS or capabilities, but simply
set u+s on chown program.
With just a "whoami" in the some_destructive_script.sh
But 2 things prevented this from happening:
- chown cleared the setuid bit
- setuid doesn t work in scripts (only in binaries).
- if you run "/bin/sh some_destructive_script.sh" , you are owner of the
sh job, so the permissions on the script file don t apply.

So the risk is not so obvious, but juging from CERT notes and such, it
really considered as a risk.
 
fogh wrote:
David Cuthbert wrote:
The immediate security risk that comes to mind:
chmod 4755 some_destructive_script.sh
chown user some_destructive_script.sh
/bin/sh some_destructive_script.sh

And you're now running that script as that user.


I tried this on linux, on a local filesystem. Indeed it is disabled by
default there too. I did not use the LIDS or capabilities, but simply
set u+s on chown program.
With just a "whoami" in the some_destructive_script.sh
But 2 things prevented this from happening:
- chown cleared the setuid bit
- setuid doesn t work in scripts (only in binaries).
- if you run "/bin/sh some_destructive_script.sh" , you are owner of the
sh job, so the permissions on the script file don t apply.

So the risk is not so obvious, but juging from CERT notes and such, it
really considered as a risk.
Ah, I made two goofs:
1. chmod and chown should be reversed (as you noted).
2. /bin/sh some_destructive_script.sh should be just
./some_destructive_script.sh

On traditional Unix systems, scripts can be setuid (even to root), with
all the security implications this implies. Apparently, however, the
Linux kernel has disabled setuid scripts (probably wise, though there
might be some obscure issues with this that I'm not aware of).

--
David Cuthbert dacut at cadence dot com
Cadence Design Systems +1 (412) 599-1820
 
Hi Fogh,

You need to type "umask 002" in the terminal window before starting
icfb. That will give all files created or editted group read and write
permissions.

Tim
 
fogh wrote:
When I edit and then save a schematic that belongs to johndoe, it
ends up
owned by me and having my umask as permissions.

Is there a way to alter this behavior and get the "save" to do just
this
(save) and no fooling around with ownership/permissions ?
I don't know if there's any significant difference between OA and cdb
in this regard.

I believe the Virtuoso drill for saving .cdb is essentially:

0) unlink .cd%
1) mv .cdb .cd% (via rename(2) or the equiv)
2) create & write a new .cdb

I'd be reluctant to change this even if I could, because
it is robust in a file-system-full scenario (except in a
really bizarre circumstance, the rename will succeed and you'll
still have a backup file even if the file system is truly 100%
and the new write fails).

In general, you won't have permission to chown the new
..cdb.

In principle, you could set a post-save callback to:

1) mv the new .cdb to .cdbnew
2) mv the old .cd% back to .cdb (owner/permission preserved).
3) copy the old .cdb to .cd%, set the mtime in .cd%
to match the old .cdb (lose the owner, but you can't
help that).
3) write the the contents of .cdbnew back over the old .cdb
(hence inheriting the old owner/permissions).
4) unlink .cdbnew

SKILL gives you renameFile(), so you can almost do this in
SKILL; but no way I know of to set mtime from generic SKILL.

-Jay-
 
David Cuthbert wrote:
fogh wrote:
jayl-news@accelerant.net wrote:
In general, you won't have permission to chown the new
.cdb.
I don t understand why. Since the new cdb belongs to me (the SKILL
trigger job owner), I should be able to change permission to the same
as cd% and then give ownership to owner of cd% ?
Am I missing something ?

chown is a priviledged (root) operation.

With some of the new caps models out there, it's possible (but a major
security risk) to grant this to normal users (CAP_CHOWN on SELinux, for
example).
I never even noticed. I have been using chown to give away files as normal
user to other normal users on HPUX11i , solaris8 and redhat7.3 for years without
noticing.
(But it seems to be the default on solaris8 tho.) What other OS/security
settings have this restriction by default ? What security risk does it pose ?
 

Welcome to EDABoard.com

Sponsor

Back
Top