bugGNU CSSC - Bugs: bug #36269, "sccs create" loses...

 
 

bug #36269: "sccs create" loses execute permissions

Submitted by:  None
Submitted on:  Sun 22 Apr 2012 01:47:08 AM UTC  
 
Category: NoneSeverity: 3 - Normal
Item Group: NoneStatus: Fixed
Privacy: PublicAssigned to: James Youngman <jay>
Open/Closed: Open

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Wed 06 Aug 2014 12:22:05 PM UTC, comment #5:

Just a note: SCCS does not intend to exactly reproduce the
permissions of a file. It just likes to permit a user to make
a script executable in order to be able to check it.

BitKeeper SCCS does include support for reproducing arbitrary
permissions but this is not really compatible with the ideas
of SCCS. Future versions of SCCS may incluse some kind of similar
support.

The man pages of the original SCCS have been rewritten to include
more information. This includes previously undocumented feaatures
that some people may rely on. I recommend you to have a look at
the SCCS man pages at:

http://sccs.sourceforge.net/man/index.html

in special at:

http://sccs.sourceforge.net/man/sccsfile.4.html

as this now includes some information about propertoes where
CSSC deviates from SCCS.

See also sccs.sourceforge.net for the SCCS homepage.

Jörg Schilling <schily>
Mon 28 Jul 2014 12:30:39 AM UTC, comment #4:

I reconsidered my previous position.

It's least astonishing for us to treat execute bits as we do read bits; if the umask permits, the gotten file is world-readable; the previous mode of other files doesn't affect it. Hence if the history file is executable it's least surprising for the gotten file to be mode 0777 (modified by the umask). This is the Solaris behaviour.

Setting world-execute permissions on the gotten file is unlikely to grant additional access to anybody since (subject to umask) they can read the gotten file anyway (hence copy it and chmod it themselves).

I've implemented the feature: http://git.savannah.gnu.org/cgit/cssc.git/commit/?id=cb5e4ca42dc01103228d662911be5144da4cb2d5

James Youngman <jay>
Project AdministratorIn charge of this item.
Sun 20 Jul 2014 11:01:42 PM UTC, comment #3:

Correction -- remove a spurious "not":

mode 0666 (if the original file was not owner-executable) or mode 0777 (if the original file was owner-executable).

James Youngman <jay>
Project AdministratorIn charge of this item.
Sun 20 Jul 2014 10:59:57 PM UTC, comment #2:

I'm inclined to implement the feature, but closely following the behaviour of Solaris 10 in particular (I didn't check other versions) may not be the best approach, since that implementation somewhat violates the principle of least astonishment:

When reading the input file (named via admin -i, for example) only the owner's execute permission bit is significant. The setting of this bit is copied however to all three of the execute bits in the history file [note 1] if the input , and in turn that is copied to the mode bits of the subsequent gotten file.

The result is that you take a file executable by owner only, check it into SCCS, check it out again, and suddenly it's world-executable (depending on your umask).

[note 1]: I assume this happens because the history file and the gotten file are created with mode 0666 (if the original file was not owner-executable) or mode 0777 (if the original file was not owner-executable).

( for mask in 0111 0011 0001 0000; do umask $mask; echo; echo umask=$mask; rm -f
s.x; touch x; chmod 0750 x; echo Original mode:; ls -ld x; admin -i s.x < x 2>/dev/null ; echo Mode of resulting history file:; ls -l s.x; rm -f x; get s.x >/dev/null 2>&1; echo Mode of gotten file:; ls -l x; rm -f x s.x; done )

umask=0111
Original mode:
-rwxr-x--- 1 jay csw 0 Jul 21 00:48 x
Mode of resulting history file:
-r--r--r-- 1 jay csw 146 Jul 21 00:48 s.x
Mode of gotten file:
-r--r--r-- 1 jay csw 0 Jul 21 00:48 x

umask=0011
Original mode:
-rwxr-x--- 1 jay csw 0 Jul 21 00:48 x
Mode of resulting history file:
-r-xr--r-- 1 jay csw 146 Jul 21 00:48 s.x
Mode of gotten file:
-r-xr--r-- 1 jay csw 0 Jul 21 00:48 x

umask=0001
Original mode:
-rwxr-x--- 1 jay csw 0 Jul 21 00:48 x
Mode of resulting history file:
-r-xr-xr-- 1 jay csw 146 Jul 21 00:48 s.x
Mode of gotten file:
-r-xr-xr-- 1 jay csw 0 Jul 21 00:48 x

umask=0000
Original mode:
-rwxr-x--- 1 jay csw 0 Jul 21 00:48 x
Mode of resulting history file:
-r-xr-xr-x 1 jay csw 146 Jul 21 00:48 s.x
Mode of gotten file:
-r-xr-xr-x 1 jay csw 0 Jul 21 00:48 x

If the original file is not owner-executable, the history file (and this subsequent gotten files) are not executable at all:

( for mask in 0111 0011 0001 0000; do umask $mask; echo; echo umask=$mask; rm -f
s.x; touch x; chmod 0651 x; echo Original mode:; ls -ld x; admin -i s.x < x 2>/dev/null ; echo Mode of resulting history file:; ls -l s.x; rm -f x; get s.x >/dev/null 2>&1; echo Mode of gotten file:; ls -l x; rm -f x s.x; done )

umask=0111
Original mode:
-rw-r-x--x 1 jay csw 0 Jul 21 00:57 x
Mode of resulting history file:
-r--r--r-- 1 jay csw 146 Jul 21 00:57 s.x
Mode of gotten file:
-r--r--r-- 1 jay csw 0 Jul 21 00:57 x

umask=0011
Original mode:
-rw-r-x--x 1 jay csw 0 Jul 21 00:57 x
Mode of resulting history file:
-r--r--r-- 1 jay csw 146 Jul 21 00:57 s.x
Mode of gotten file:
-r--r--r-- 1 jay csw 0 Jul 21 00:57 x

umask=0001
Original mode:
-rw-r-x--x 1 jay csw 0 Jul 21 00:57 x
Mode of resulting history file:
-r--r--r-- 1 jay csw 146 Jul 21 00:57 s.x
Mode of gotten file:
-r--r--r-- 1 jay csw 0 Jul 21 00:57 x

umask=0000
Original mode:
-rw-r-x--x 1 jay csw 0 Jul 21 00:57 x
Mode of resulting history file:
-r--r--r-- 1 jay csw 146 Jul 21 00:57 s.x
Mode of gotten file:
-r--r--r-- 1 jay csw 0 Jul 21 00:57 x

James Youngman <jay>
Project AdministratorIn charge of this item.
Tue 15 Jul 2014 01:32:22 PM UTC, comment #1:

You may like to use the original SCCS then, see:

https://sourceforge.net/projects/sccs/files/

or

https://sourceforge.net/projects/schilytools/files/ for development snapshots

Jörg Schilling <schily>
Sun 22 Apr 2012 01:47:08 AM UTC, original submission:

An "sccs create myfile" command, where myfile had execute permissions beforehand, destroys those execute permissions. This is an inappropriate intrusion, and does not mirror the behavior of standard SCCS (e.g., on Solaris). Standard SCCS copies the execute permissions to the SCCS/s.myfile file, and does not remove them from the original file.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by jay (Posted a comment)
  • -unavailable- added by schily (Posted a comment)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 28 Jul 2014 12:30:39 AM UTCjayStatusNone=>Fixed
    Sun 20 Jul 2014 10:59:57 PM UTCjayAssigned toNone=>jay

    Back to the top


    Powered by Savane 3.1-cleanup