I think you may be getting too deep into the detail.
Think of the bigger picture:
when I move a file, I don't expect that to change its ownership or
permissions - it would surprise me if it did;
when I make a copy of a file, I expect to own the copy - after all, what use
is a private copy I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Jonathan McKeown wrote:
The bit that still worries me in this discussion is the sgid bit (pun not
intended, but I'm not going to delete it now!): as I understand it, creating
a file has different behaviour on SYSV-derived systems and
doesn't know anything about gid 80.
Now, on HostClient, user copies aFile to /share/www using the -p flag of
cp(1).
cp -p aFile /share/www/
ls -l
-rw--- 1 user user 2981888 Feb 7 01:09 /www/aFile
As shown, the setgid flag of /www hasn't worked.
Hang on - you asked cp to preserve
on /share/www. HostClient
doesn't know anything about gid 80.
Now, on HostClient, user copies aFile to /share/www using the -p flag of
cp(1).
cp -p aFile /share/www/
ls -l
-rw--- 1 user user 2981888 Feb 7 01:09 /www/aFile
As shown, the setgid flag of /www hasn't worked.
Hang on - you
Ok, my view is getting clearer ;-)
my problem in understanding the semantics of mv, cp -p and the rename(2)
function seems to be related to the terminology used in chmod(1) man page.
This is the explanation of setuid (the same holds for setgid):
Directories with this bit set will force all
Now, from a logical point of view, why moving a file into a directory
doesn't fall into the created into them case?
Because (if on the same filesystem) you don't create a new file. You
just link the file in the destination dir and unlink the file from the
source dir.
Exactly. But
, Pietro Cerutti [EMAIL PROTECTED]:
Ok, my view is getting clearer ;-)
my problem in understanding the semantics of mv, cp -p and the rename(2)
function seems to be related to the terminology used in chmod(1) man page.
This is the explanation of setuid (the same holds for setgid):
Directories
Wouter Oosterveld wrote:
Now, from a logical point of view, why moving a file into a directory
doesn't fall into the created into them case?
Because (if on the same filesystem) you don't create a new file. You
just link the file in the destination dir and unlink the file from the
source
On Fri, Feb 08, 2008 at 12:30:57PM +0100, Pietro Cerutti wrote:
Wouter Oosterveld wrote:
Now, from a logical point of view, why moving a file into a directory
doesn't fall into the created into them case?
Because (if on the same filesystem) you don't create a new file. You
just link
Chuck Swiger wrote:
On Feb 7, 2008, at 10:42 AM, Pietro Cerutti wrote:
From HostClient:
ls -al /share/
drwxr-sr-x 4 User www 512 Feb 7 19:23 www
touch /share/www/foo
ls -l /share/www/foo
-rw-r- 1 user www 0 Feb 7 19:39 /share/www/foo
(group id works)
Right, this
Pietro Cerutti wrote:
Chuck Swiger wrote:
On Feb 7, 2008, at 10:07 AM, Pietro Cerutti wrote:
here's the situation:
HostServer exports via NFS /www, which belongs to user:www
(uid=1001, gid=80). The directory has the segid flag set:
drwsr-xr-x 13 user www 512 Feb 7 00:58 www
Umm, that
Chuck Swiger wrote:
On Feb 7, 2008, at 10:07 AM, Pietro Cerutti wrote:
here's the situation:
HostServer exports via NFS /www, which belongs to user:www
(uid=1001, gid=80). The directory has the segid flag set:
drwsr-xr-x 13 user www 512 Feb 7 00:58 www
Umm, that directory you show has
On Feb 7, 2008, at 10:07 AM, Pietro Cerutti wrote:
here's the situation:
HostServer exports via NFS /www, which belongs to user:www
(uid=1001, gid=80). The directory has the segid flag set:
drwsr-xr-x 13 user www 512 Feb 7 00:58 www
Umm, that directory you show has the setuid bit set, not
.
Now, on HostClient, user copies aFile to /share/www using the -p flag of
cp(1).
cp -p aFile /share/www/
ls -l
-rw--- 1 user user 2981888 Feb 7 01:09 /www/aFile
As shown, the setgid flag of /www hasn't worked.
Now in man cp, I can read the following:
If the source file has its set-user
On Feb 7, 2008, at 10:42 AM, Pietro Cerutti wrote:
From HostClient:
ls -al /share/
drwxr-sr-x 4 User www 512 Feb 7 19:23 www
touch /share/www/foo
ls -l /share/www/foo
-rw-r- 1 user www 0 Feb 7 19:39 /share/www/foo
(group id works)
Right, this is the BSD setgid
Hi folks,
FreeBSD 5.4-RELEASE-p6 i386
We have a script in our environment that is used to back up our mail
logs. In essence it does:
cp -p /var/log/maillog.0.bz2 /stats/maillogs/maillog-testcopy.bz2
According to the cp man page:
snip
-p Cause cp to preserve the following attributes
You need to run this as root so the permissions and ownership all can be
set.
-Derek
On Mon, 28 Aug 2006, Gabriel O'Brien wrote:
Hi folks,
FreeBSD 5.4-RELEASE-p6 i386
We have a script in our environment that is used to back up our mail logs.
In essence it does:
cp -p /var/log
is displayed and the exit value is not altered.
However, when I run this script or when I do a cp -p manually I am
seeing:
cp: chown: /stats/maillogs/maillog-copy-test.bz2: Permission denied
You need to run this as root so the permissions and ownership all
can be set.
-Derek
I
18 matches
Mail list logo
